Bài giảng Introduction to Software Engineering - Week 4: Requirement Engineering - Nguyễn Thị Minh Tuyền

d the photos, the originals are overwritten. If they chose to
 rename the photos, a new name is automatically generated by adding a
 number to the existing file name.
£ Other activities: The moderator may be logged on to the system and
 may approve photos as they are uploaded.
£ System state on completion: User is logged on. The selected photos
 have been uploaded and assigned a status ‘awaiting moderation’. Photos
 are visible to the moderator and to the user who uploaded them.
 46
 Topics covered
1. Functional and non-functional requirements
2. Requirements engineering processes
3. Requirements elicitation and analysis
4. Requirements specification
5. Requirements validation
6. Requirements management
 47
48
 Requirements specification
£ The process of writing down the user and system
 requirements in a requirements document.
£ User requirements have to be understandable by end-
 users and customers who do not have a technical
 background.
£ System requirements are more detailed requirements
 and may include more technical information.
 p May be part of a contract for the system development
 p Should therefore be a complete and detailed specification of the
 whole system.
 49
 Requirements and design
£ In principle:
 p requirements should state what the system should do and
 p the design should describe how it does this.
£ In practice: requirements and design are inseparable
 p A system architecture may be designed to structure the
 requirements;
 p The system may inter-operate with other systems that generate
 design requirements;
 p The use of a specific architecture to satisfy non-functional
 requirements may be a domain requirement.
 p This may be the consequence of a regulatory requirement.
 50
 Ways of writing a system 
 requirements specification 
1. Natural language
2. Structured natural language
3. Design description languages
4. Graphical notations
5. Mathematical specifications
 51
 Natural language specification
£ Requirements are written as natural language
 sentences supplemented by diagrams and tables.
£ Used for writing requirements because it is
 expressive, intuitive and universal.
 p This means that the requirements can be understood by
 users and customers.
 52
 Guidelines for writing requirements
£ Invent a standard format and use it for all
 requirements.
£ Use language in a consistent way.
£ 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.
 53
 Problems with natural language
£ Lack of clarity
£ Requirements confusion
£ Requirements amalgamation
 54
 Example
Requirements for the insulin pump software system
 3.2 The system shall measure the blood sugar and deliver 
 insulin, if required, every 10 minutes. (Changes in blood 
 sugar are relatively slow so more frequent measurement is 
 unnecessary; less frequent measurement could lead to 
 unnecessarily high sugar levels.)
 3.6 The system shall run a self-test routine every minute with 
 the conditions to be tested and the associated actions 
 defined. (A self-test routine can discover hardware and 
 software problems and alert the user to the fact the normal 
 operation may be impossible.)
 55
 Structured specifications
£ The freedom of the requirements writer is limited
 and requirements are written in a standard way.
£ This approach maintains most of the
 expressiveness and understandability of natural
 language but ensures that some uniformity is
 imposed on the specification
£ This works well for some types of requirements
 e.g. requirements for embedded control system
 but is sometimes too rigid for writing business
 system requirements.
 56
 A structured specification of a 
 requirement for an insulin pump [1]
Insulin Pump/Control Software/SRS/3.3.2
Function Compute insulin dose: safe sugar level.
Description
Computes the dose of insulin to be delivered when the current
measured sugar level is in the safe zone between 3 and 7 units.
Inputs
Current sugar reading (r2); the previous two readings (r0 and r1).
Source
Current sugar reading from sensor. Other readings from memory.
Outputs CompDose—the dose in insulin to be delivered.
Destination Main control loop.
 57
 A structured specification of a 
 requirement for an insulin pump [2]
Action
CompDose is zero if the sugar level is stable or falling or if the level is
increasing but the rate of increase is decreasing. If the level is increasing and
the rate of increase is increasing, then CompDose is computed by dividing the
difference between the current sugar level and the previous level by 4 and
rounding the result. If the result, is rounded to zero then CompDose is set to
the minimum dose that can be delivered.
Requirements
Two previous readings so that the rate of change of sugar level can be
computed.
Pre-condition
The insulin reservoir contains at least the maximum allowed single dose of
insulin.
Post-condition r0 is replaced by r1 then r1 is replaced by r2.
Side effects None.
 58
 Tabular specification
£ Used to supplement natural language.
£ Particularly useful when you have to define a
 number of possible alternative courses of action.
£ For example:
 p the insulin pump systems bases its computations on the
 rate of change of blood sugar level and the tabular
 specification explains how to calculate the insulin
 requirement for different scenarios.
 59
 Tabular specification of computation 
 for an insulin pump
 Condition Action
Sugar level falling (r2 < r1) CompDose = 0
Sugar level stable (r2 = r1) CompDose = 0
Sugar level increasing and rate of increase CompDose = 0
decreasing ((r2 – r1) < (r1 – r0))
Sugar level increasing and rate of increase CompDose = round ((r2 – r1)/4)
stable or increasing ((r2 – r1) ≥ (r1 – r0)) If rounded result = 0 then
 CompDose = MinimumDose
 60
 Use cases
£ Use-cases are a kind of scenario that are included
 in the UML.
£ Use cases 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
£ UML sequence diagrams may be used to add
 detail to use-cases by showing the sequence of
 event processing in the system.
 61
 Use cases for the Mentcare system
 Register Export
 patient statistics
 View Manager
 Generate
Medical receptionist personal info.
 report
 View record
 Nurse
 Doctor
 Edit record
 Setup
 consultation 62
 The software requirements 
 document
£ The software requirements document is the official
 statement of what is required of the system
 developers.
£ 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 HOW it should do it.
 63
Users of a requirements document
 Specify the requirements and
 System read them to check that they
 customers meet their needs. Customers
 specify changes to the
 requirements.
 Use the requirements
 Managers document to plan a bid for
 the system and to plan the
 system development process.
 System Use the requirements to
 engineers understand what system is
 to be developed.
 System test Use the requirements to
 engineers develop validation tests for
 the system.
 System Use the requirements to
 maintenance understand the system and 64
 engineers the relationships between its
 parts.
 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.
 65
 Structure of a requirements document
Chapter Description
Preface This should define the expected readership of the document and describe 
 its version history, including a rationale for the creation of a new version 
 and a summary of the changes made in each version. 
Introduction This should describe the need for the system. It should briefly describe the 
 system’s functions and explain how it will work with other systems. It 
 should also describe how the system fits into the overall business or 
 strategic objectives of the organization commissioning the software.
Glossary This should define the technical terms used in the document. You should 
 not make assumptions about the experience or expertise of the reader.
User requirements Here, you describe the services provided for the user. The nonfunctional 
definition system requirements should also be described in this section. This 
 description may use natural language, diagrams, or other notations that are 
 understandable to customers. Product and process standards that must be 
 followed should be specified.
System architecture This chapter should present a high-level overview of the anticipated system 
 architecture, showing the distribution of functions across system modules. 
 Architectural components that are reused should be highlighted.
 66
 Structure of a requirements 
 document
 Chapter Description
System This should describe the functional and nonfunctional requirements in more detail. 
requirements If necessary, further detail may also be added to the nonfunctional requirements. 
specification Interfaces to other systems may be defined.
System models This might include graphical system models showing the relationships between 
 the system components and the system and its environment. Examples of 
 possible models are object models, data-flow models, or semantic data models. 
System evolution This should describe the fundamental assumptions on which the system is based, 
 and any anticipated changes due to hardware evolution, changing user needs, 
 and so on. This section is useful for system designers as it may help them avoid 
 design decisions that would constrain likely future changes to the system.
Appendices These should provide detailed, specific information that is related to the 
 application being developed; for example, hardware and database descriptions. 
 Hardware requirements define the minimal and optimal configurations for the 
 system. Database requirements define the logical organization of the data used 
 by the system and the relationships between data. 
Index Several indexes to the document may be included. As well as a normal alphabetic 
 index, there may be an index of diagrams, an index of functions, and so on.
 67
 Topics covered
1. Functional and non-functional requirements
2. Requirements engineering processes
3. Requirements elicitation and analysis
4. Requirements specification
5. Requirements validation
6. Requirements management
 68
 Requirements validation
£ Concerned with demonstrating that the
 requirements define the system that the customer
 really wants.
£ Requirements error costs are high so validation is
 very important
 p Fixing a requirements error after delivery may cost up to
 100 times the cost of fixing an implementation error.
 69
 Requirements checking
£ Validity
 p Does the system provide the functions which best
 support the customer’s needs?
£ Consistency
 p Are there any requirements conflicts?
£ Completeness
 p Are all functions required by the customer
 included?
£ Realism
 p Can the requirements be implemented given
 available budget and technology
£ Verifiability 70
 ptheCanrequirements be checked?
 Requirements validation techniques
£ Requirements reviews
 p Systematic manual analysis of the requirements.
£ Prototyping
 p Using an executable model of the system to check
 requirements.
£ Test-case generation
 p Developing tests for requirements to check testability.
 71
 Requirements reviews
£ Regular reviews should be held while the
 requirements definition is being formulated.
£ Both client and contractor staff should be involved
 in reviews.
£ Reviews may be formal (with completed
 documents) or informal. Good communications
 between developers, customers and users can
 resolve problems at an early stage.
 72
 Review checks
£ Verifiability
 p Is the requirement realistically testable?
£ Comprehensibility
 p Is the requirement properly understood?
£ Traceability
 p Is the origin of the requirement clearly stated?
£ Adaptability
 p Can the requirement be changed without a large impact
 on other requirements?
 73
 Topics covered
1. Functional and non-functional requirements
2. Requirements specification
3. Requirements engineering processes
4. Requirements elicitation and analysis
5. Requirements validation
6. Requirements management
 74
 Changing requirements
£ The business and technical environment of the
 system always changes after installation.
£ The people who pay for a system and the users of
 that system are rarely the same people.
£ Large systems usually have a diverse user
 community, with many users having different
 requirements and priorities that may be conflicting
 or contradictory.
 75
 Requirements management
£ Is the process of managing changing
 requirements during the requirements
 engineering process and system
 development.
£ You need to
 p keep track of individual requirements and maintain
 links between dependent requirements so that you
 can assess the impact of requirements changes.
 p establish a formal process for making change
 proposals and linking these to system
 requirements.
 76
 Requirements evolution
 Initial Changed
understanding understanding
 of problem of problem
 Initial Changed
 requirements requirements
 Time
 77
 Requirements management 
 planning
£ Planning is an essential first stage, it establishes the
 level of requirements management detail that is required.
£ During the requirements management, we have to
 decide on:
 p Requirements identification Each requirement must be
 uniquely identified so that it can be cross-referenced with
 other requirements.
 p A change management process This is the set of
 activities that assess the impact and cost of changes.
 p Traceability policies These policies define the
 relationships between each requirement and between the
 requirements and the system design that should be
 recorded.
 78
 p Tool support Tools that may be used range from specialist
 requirements management systemsspreadsheetsto and
 Requirements change management
Identified Revised
problem Problem analysis and Change analysis Change requirements
 change specification and costing implementation
 79
Questions?
 80