intTypePromotion=1
zunia.vn Tuyển sinh 2024 dành cho Gen-Z zunia.vn zunia.vn
ADSENSE
 » 
 » 

Bài giảng Công nghệ phần mềm: Chapter 3 - Nguyễn Thị Cẩm Hương

Chia sẻ: Sơn Nam | Ngày: | Loại File: PDF | Số trang:11

Thêm vào BST
Báo xấu
85
lượt xem 4
download
 
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Bài giảng "Công nghệ phần mềm - Chapter 3: Requirements Engineering" presentation of content: Functional and non-functional requirements, the software requirements document, requirements specification, requirements engineering processes,... Invite you to reference.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Bài giảng Công nghệ phần mềm: Chapter 3 - Nguyễn Thị Cẩm Hương

  1. 2/25/2016 Topics covered  Functional and non-functional requirements  The software requirements document Chapter 3 – Requirements Engineering  Requirements specification  Requirements engineering processes  Requirements elicitation and analysis Lecture 1  Requirements validation  Requirements management Chapter3 Requirements engineering 1 Chapter3 Requirements engineering 2 Readers of different types of requirements Requirements engineering specification  Requirements engineering  What is a requirement?  Types of requirement  User requirements  System requirements Chapter3 Requirements engineering 3 Chapter3 Requirements engineering 4 Functional and non-functional requirements Functional requirements  Describe functionality or system services.  Functional requirements  Non-functional requirements  Depend on the type of software, expected users and the type of system where the software is used.  Domain requirements  Functional user requirements may be high-level statements of what the system should do.  Functional system requirements should describe the system services in detail. Chapter3 Requirements engineering 5 Chapter3 Requirements engineering 6 1
  2. 2/25/2016 Requirements imprecision Requirements completeness and consistency  Problems arise when requirements are not precisely  In principle, requirements should be both complete and stated. consistent.  Ambiguous requirements may be interpreted in different  Complete ways by developers and users.  Consistent  Consider the term ‘search’ in requirement 1  In practice, it is impossible to produce a complete and consistent requirements document.  User intention – search for a patient name across all appointments in all clinics;  Developer interpretation – search for a patient name in an individual clinic. User chooses clinic then search. Chapter3 Requirements engineering 7 Chapter3 Requirements engineering 8 Non-functional requirements Types of nonfunctional requirement  These define system properties and constraints  Process requirements may also be specified mandating a particular IDE, programming language or development method.  Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless. Chapter3 Requirements engineering 9 Chapter3 Requirements engineering 10 Non-functional requirements implementation Non-functional classifications  Non-functional requirements may affect the overall  Product requirements architecture of a system rather than the individual  Organisational requirements components.  For example, to ensure that performance requirements are met,  External requirements you may have to organize the system to minimize communications between components.  A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required.  It may also generate requirements that restrict existing requirements. Chapter3 Requirements engineering 11 Chapter3 Requirements engineering 12 2
  3. 2/25/2016 Metrics for specifying nonfunctional Goals and requirements requirements  Non-functional requirements may be very difficult to state Property Measure precisely and imprecise requirements may be difficult to Speed Processed transactions/second User/event response time verify. Screen refresh time Size Mbytes  Goal Number of ROM chips  A general intention of the user such as ease of use. Ease of use Training time Number of help frames  Verifiable non-functional requirement Reliability Mean time to failure  A statement using some measure that can be objectively tested. Probability of unavailability Rate of failure occurrence  Goals are helpful to developers as they convey the Availability intentions of the system users. Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems Chapter3 Requirements engineering 13 Chapter3 Requirements engineering 14 Domain requirements Domain requirements problems  The system’s operational domain imposes requirements  Understandability on the system.  Implicitness  For example, a train control system has to take into account the braking characteristics in different weather conditions.  Domain requirements be new functional requirements, constraints on existing requirements or define specific computations.  If domain requirements are not satisfied, the system may be unworkable. Chapter3 Requirements engineering 15 Chapter3 Requirements engineering 16 The software requirements document  The software requirements document is the official statement of what is required of the system developers. Chapter 4 – Requirements Engineering  Should include both a definition of user requirements and a specification of the system requirements.  It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than Lecture 2 HOW it should do it. Chapter3 Requirements engineering 17 Chapter3 Requirements engineering 18 3
  4. 2/25/2016 Users of a requirements document Requirements document variability  Information in requirements document depends on type of system and the approach to development used.  Systems developed incrementally will, typically, have less detail in the requirements document.  Requirements documents standards have been designed e.g. IEEE standard. These are mostly applicable to the requirements for large systems engineering projects. Chapter3 Requirements engineering 19 Chapter3 Requirements engineering 20 The structure of a requirements document Requirements specification  The process of writing don the user and system Chapter requirements in a requirements document. 1. Preface 6. System requirements specification  User requirements have to be understandable by end- users and customers who do not have a technical 2. Introduction 7. System models background.  System requirements are more detailed requirements 3. Glossary 8. System evolution and may include more technical information. 4. User requirements definition 9. Appendices  The requirements may be part of a contract for the system development 5. System architecture 10. Index  It is therefore important that these are as complete as possible. Chapter3 Requirements engineering 21 Chapter3 Requirements engineering 22 Ways of writing a system requirements Requirements and design specification Notation  In principle, requirements should state what the system Natural language should do and the design should describe how it does this. Structured natural language  In practice, requirements and design are inseparable Design description languages  A system architecture may be designed to structure the requirements; Graphical notations  The system may inter-operate with other systems that generate design requirements; Mathematical specifications  The use of a specific architecture to satisfy non-functional requirements may be a domain requirement.  This may be the consequence of a regulatory requirement. Chapter3 Requirements engineering 23 4
  5. 2/25/2016 Natural language specification Guidelines for writing requirements  Requirements are written as natural language sentences  Invent a standard format and use it for all requirements. supplemented by diagrams and tables.  Use language in a consistent way. Use shall for  Used for writing requirements because it is expressive, mandatory requirements, should for desirable intuitive and universal. This means that the requirements requirements. can be understood by users and customers.  Use text highlighting to identify key parts of the requirement.  Avoid the use of computer jargon.  Include an explanation (rationale) of why a requirement is necessary. Chapter3 Requirements engineering 25 Example requirements for the insulin pump Problems with natural language software system  Lack of clarity  Precision is difficult without making the document difficult to 3.2 The system shall measure the blood sugar and deliver read. insulin, if required, every 10 minutes. (Changes in blood sugar are relatively slow so more frequent measurement is  Requirements confusion unnecessary; less frequent measurement could lead to  Functional and non-functional requirements tend to be mixed-up. unnecessarily high sugar levels.)  Requirements amalgamation 3.6 The system shall run a self-test routine every minute with  Several different requirements may be expressed together. the conditions to be tested and the associated actions defined in Table 1. (A self-test routine can discover hardware and software problems and alert the user to the fact the normal operation may be impossible.) Chapter3 Requirements engineering 28 Structured specifications Form-based specifications  An approach to writing requirements where the freedom  Definition of the function or entity. of the requirements writer is limited and requirements  Description of inputs and where they come from. are written in a standard way.  Description of outputs and where they go to.  This works well for some types of requirements e.g. requirements for embedded control system but is  Information about the information needed for the sometimes too rigid for writing business system computation and other entities used. requirements.  Description of the action to be taken.  Pre and post conditions (if appropriate).  The side effects (if any) of the function. Chapter3 Requirements engineering 29 5
  6. 2/25/2016 A structured specification of a requirement for A structured specification of a requirement for an insulin pump an insulin pump Chapter3 Requirements engineering 31 Chapter3 Requirements engineering 32 Tabular specification of computation for an Tabular specification insulin pump  Used to supplement natural language. Condition Action  Particularly useful when you have to define a number of Sugar level falling (r2 < r1) CompDose = 0 possible alternative courses of action. Sugar level stable (r2 = r1) CompDose = 0  For example, the insulin pump systems bases its Sugar level increasing and rate of CompDose = 0 computations on the rate of change of blood sugar level increase decreasing and the tabular specification explains how to calculate ((r2 – r1) < (r1 – r0)) the insulin requirement for different scenarios. Sugar level increasing and rate of CompDose = increase stable or increasing round ((r2 – r1)/4) ((r2 – r1) ≥ (r1 – r0)) If rounded result = 0 then CompDose = MinimumDose Chapter3 Requirements engineering 34 A spiral view of the requirements engineering Requirements engineering processes process  The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.  However, there are a number of generic activities common to all processes  Requirements elicitation;  Requirements analysis;  Requirements validation;  Requirements management.  In practice, RE is an iterative activity in which these processes are interleaved. Chapter3 Requirements engineering 35 Chapter3 Requirements engineering 36 6
  7. 2/25/2016 Requirements elicitation and analysis Problems of requirements analysis  Sometimes called requirements elicitation or  Stakeholders don’t know what they really want. requirements discovery.  Stakeholders express requirements in their own terms.  Involves technical staff working with customers to find  Different stakeholders may have conflicting out about the application domain, the services that the requirements. system should provide and the system’s operational constraints.  Organisational and political factors may influence the system requirements.  May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These  The requirements change during the analysis process. are called stakeholders. New stakeholders may emerge and the business environment may change. Chapter3 Requirements engineering 37 Chapter3 Requirements engineering 38 The requirements elicitation and analysis Requirements elicitation and analysis process  Software engineers work with a range of system stakeholders to find out about the application domain, the services that the system should provide, the required system performance, hardware constraints, other systems, etc.  Stages include:  Requirements discovery,  Requirements classification and organization,  Requirements prioritization and negotiation,  Requirements specification. Chapter3 Requirements engineering 39 Chapter3 Requirements engineering 40 Process activities  Requirements discovery  Requirements classification and organisation  Prioritisation and negotiation Chapter 4 – Requirements Engineering  Requirements specification Lecture 3 Chapter3 Requirements engineering 42 7
  8. 2/25/2016 Requirements discovery Stakeholders in the MHC-PMS  The process of gathering information about the required  Patients whose information is recorded in the system. and existing systems and distilling the user and system  Doctors who are responsible for assessing and treating requirements from this information. patients.  Interaction is with system stakeholders from managers to  Nurses who coordinate the consultations with doctors external regulators. and administer some treatments.  Systems normally have a range of stakeholders.  Medical receptionists who manage patients’ appointments.  IT staff who are responsible for installing and maintaining the system. Chapter3 Requirements engineering 43 Chapter3 Requirements engineering 44 Stakeholders in the MHC-PMS Interviewing  A medical ethics manager who must ensure that the  Formal or informal interviews with stakeholders are part system meets current ethical guidelines for patient care. of most RE processes.  Health care managers who obtain management  Types of interview information from the system.  Closed interviews based on pre-determined list of questions  Medical records staff who are responsible for ensuring  Open interviews where various issues are explored with stakeholders. that system information can be maintained and preserved, and that record keeping procedures have  Effective interviewing been properly implemented.  Be open-minded, avoid pre-conceived ideas about the requirements and are willing to listen to stakeholders.  Prompt the interviewee to get discussions going using a springboard question, a requirements proposal, or by working together on a prototype system. Chapter3 Requirements engineering 45 Chapter3 Requirements engineering 46 Interviews in practice Scenarios  Normally a mix of closed and open-ended interviewing.  Scenarios are real-life examples of how a system can be  Interviews are good for getting an overall understanding used. of what stakeholders do and how they might interact with  They should include the system.  A description of the starting situation;  Interviews are not good for understanding domain  A description of the normal flow of events; requirements  A description of what can go wrong;  Requirements engineers cannot understand specific domain  Information about other concurrent activities; terminology;  Some domain knowledge is so familiar that people find it hard to  A description of the state when the scenario finishes. articulate or think that it isn’t worth articulating. 8
  9. 2/25/2016 Scenario for collecting medical history in MHC- Scenario for collecting medical history in MHC- PMS PMS Chapter3 Requirements engineering 49 Chapter3 Requirements engineering 50 Use cases Use cases for the MHC-PMS  Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself.  A set of use cases should describe all possible interactions with the system.  High-level graphical model supplemented by more detailed tabular description (see Chapter 5).  Sequence diagrams may be used to add detail to use- cases by showing the sequence of event processing in the system. Chapter3 Requirements engineering 51 Chapter3 Requirements engineering 52 Requirements validation Requirements checking  Concerned with demonstrating that the requirements  Validity. Does the system provide the functions which define the system that the customer really wants. best support the customer’s needs?  Requirements error costs are high so validation is very  Consistency. Are there any requirements conflicts? important  Completeness. Are all functions required by the  Fixing a requirements error after delivery may cost up to 100 customer included? times the cost of fixing an implementation error.  Realism. Can the requirements be implemented given available budget and technology  Verifiability. Can the requirements be checked? Chapter3 Requirements engineering 53 Chapter3 Requirements engineering 54 9
  10. 2/25/2016 Requirements validation techniques Requirements reviews  Requirements reviews  Regular reviews should be held while the requirements  Systematic manual analysis of the requirements. definition is being formulated.  Prototyping  Both client and contractor staff should be involved in  Using an executable model of the system to check requirements. reviews. Covered in Chapter 2.  Test-case generation  Reviews may be formal (with completed documents) or informal. Good communications between developers,  Developing tests for requirements to check testability. customers and users can resolve problems at an early stage. Chapter3 Requirements engineering 55 Chapter3 Requirements engineering 56 Review checks Requirements management  Verifiability  Requirements management is the process of managing  Is the requirement realistically testable? changing requirements during the requirements  Comprehensibility engineering process and system development.  Is the requirement properly understood?  New requirements emerge as a system is being  Traceability developed and after it has gone into use.  Is the origin of the requirement clearly stated?  You need to keep track of individual requirements and  Adaptability maintain links between dependent requirements so that  Can the requirement be changed without a large impact on other you can assess the impact of requirements changes. requirements? You need to establish a formal process for making change proposals and linking these to system requirements. Chapter3 Requirements engineering 57 Chapter3 Requirements engineering 58 Changing requirements Changing requirements  The business and technical environment of the system  Large systems usually have a diverse user community, always changes after installation. with many users having different requirements and  New hardware may be introduced, it may be necessary to priorities that may be conflicting or contradictory. interface the system with other systems, business priorities may  The final system requirements are inevitably a compromise change (with consequent changes in the system support between them and, with experience, it is often discovered that required), and new legislation and regulations may be introduced the balance of support given to different users has to be that the system must necessarily abide by. changed.  The people who pay for a system and the users of that system are rarely the same people.  System customers impose requirements because of organizational and budgetary constraints. These may conflict with end-user requirements and, after delivery, new features may have to be added for user support if the system is to meet its goals. Chapter3 Requirements engineering 59 Chapter3 Requirements engineering 60 10
  11. 2/25/2016 Requirements evolution Requirements management planning  Establishes the level of requirements management detail that is required.  Requirements management decisions:  Requirements identification Each requirement must be uniquely identified so that it can be cross-referenced with other requirements.  A change management process This is the set of activities that assess the impact and cost of changes. I discuss this process in more detail in the following section.  Traceability policies These policies define the relationships between each requirement and between the requirements and the system design that should be recorded.  Tool support Tools that may be used range from specialist requirements management systems to spreadsheets and simple database systems. Chapter3 Requirements engineering 61 Chapter3 Requirements engineering 62 Requirements change management Requirements change management  Deciding if a requirements change should be accepted  Problem analysis and change specification • During this stage, the problem or the change proposal is analyzed to check that it is valid. This analysis is fed back to the change requestor who may respond with a more specific requirements change proposal, or decide to withdraw the request.  Change analysis and costing • The effect of the proposed change is assessed using traceability information and general knowledge of the system requirements. Once this analysis is completed, a decision is made whether or not to proceed with the requirements change.  Change implementation • The requirements document and, where necessary, the system design and implementation, are modified. Ideally, the document should be organized so that changes can be easily implemented. Chapter3 Requirements engineering 63 Chapter3 Requirements engineering 64 Group exercise A POS (Point-Of-Sale) system is a computer system typically used to manage the sales in retail stores. It includes hardware components such as a computer, a bar code scanner, a printer and also software to manage the operation of the store. The most basic function of a POS system is to handle sales. When a customer arrives at a POS counter with goods to purchase, the cashier will start a new sale transaction. When the barcode of a good is read by the POS system, it will retrieve the name and price of this good from the backend catalog system and interact with inventory system to deduce the stock amount of this good. When the sale transaction is over, the customer can pay in cash, credit card or even check. After the payment is successful, a receipt will be printed. Note that for promotion, the store frequently issue gift coupons. The customer can use the coupons for a better price when purchasing goods. Another function of a POS system is to handle returns… A user must log in to use the POS. The users of a POS system are the employees of the store including cashiers and the administrator. The administrator can access the system management Chapter3 Requirements functions of the POS system65 engineering including user management and security configuration that cashiers can’t do. 11
ADSENSE

CÓ THỂ BẠN MUỐN DOWNLOAD

THÔNG TIN
TRỢ GIÚP
HỖ TRỢ KHÁCH HÀNG
Theo dõi chúng tôi

Chịu trách nhiệm nội dung:

Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA

LIÊN HỆ

Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM

Hotline: 093 303 0098

Email: support@tailieu.vn

Giấy phép Mạng Xã Hội số: 670/GP-BTTTT cấp ngày 30/11/2015 Copyright © 2022-2032 TaiLieu.VN. All rights reserved.

 

Đồng bộ tài khoản
2=>2