Chapter 4 Requirements Engineering Chapter 4 Requirements engineering1.
Post on 30-Dec-2015
231 Views
Preview:
Transcript
S
Chapter 4 Requirements Engineering
Chapter 4 Requirements engineering1
Requirements Engineering
May be used in all software Development models Waterfall Agile Reuse Other
Chapter 4 Requirements engineering2
Requirements engineering processes
Vary widely.
Common processes Requirements elicitation; Requirements analysis; Requirements validation; Requirements management.
Typically iterative/interleaved.
Chapter 4 Requirements engineering3
Requirements Form
Document (Traditional)
Agreement (Agile)
Chapter 4 Requirements engineering4
What is a Requirement?
What is needed of the system Allow storage of name, address, phone, SSS for
employees Phone must allow for international number
Valid? Number of digits for SSS GUI toolset Programming Language
Chapter 4 Requirements engineering5
Levels of requirement
User requirements High level For customers Their terminology
System requirements Detailed For development For contacts
Chapter 4 Requirements engineering6
User and system requirements
Chapter 4 Requirements engineering7
Requirement Types
Functional Requirements Features Specific functionality More from users
Non Functional Requirements Broad concepts Apply to large functionality Performance, Capacity, Reliability, Security, Availability More from developers
Chapter 4 Requirements engineering8
Types of Requirements
Functional requirements Functionality needed
Generate map of voters Compute tips for tax reports Generate report of sales by location
Non-functional requirements Constraints
Speed Reliability Uptime Location (from any browser)
Chapter 4 Requirements engineering9
Functional Requirements
High level Calculate wages per employees
Medium Calculate standard wages Calculate tips Calculate overtime
Low Calculate standard tips Calculate distributed tips
Chapter 4 Requirements engineering10
Functional RequirementChallenge
Lack of detail
Lack of clarity
Chapter 4 Requirements engineering11
Non-functional requirements
Scope Affect large portions of project
Not specific to functionality Reliability Availability Response time Capacity (number of records) Constraints (work with an existing system) IDE Programming language Development method Coding Standards
Chapter 4 Requirements engineering12
Non-functional – Functional Link
Non functional requirement may generate many functional requirements Security
Logons Password recovery
Chapter 4 Requirements engineering13
Types of nonfunctional requirement
Chapter 4 Requirements engineering14
Measurability
Non functional requirements must be measurable
Chapter 4 Requirements engineering15
Metrics for specifying nonfunctional requirements
Chapter 4 Requirements engineering16
Property Measure
Speed Processed transactions/secondUser/event response timeScreen refresh time
Size MbytesNumber of ROM chips
Ease of use Training timeNumber of help frames
Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability
Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure
Portability Percentage of target dependent statementsNumber of target systems
Examples
All error messages will contain enough identification to locate source of problem in code.
All error messages will lead to a solution
No software installation will require system reboot.
All names in code will be self explanatory
All functionality will appear in menus or on dialogs.
All functionality can be accessed via menu or keystroke.
Chapter 4 Requirements engineering17
Domain requirements
Operational environment Train brake control system Temperature range Humidity range Gradient range
Chapter 4 Requirements engineering18
Software Requirements Doc
Agreed upon plan Critical for waterfall
review may be after extended period Less critical / formal for agile
Review/change will come soon anyway
Chapter 4 Requirements engineering19
Agile methods and requirements
Requirements Document Waste of Time Inherently out of date Replaced by user stories
Chapter 4 Requirements engineering20
The structure of a requirements document
Chapter 4 Requirements engineering21
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 definition
Here, you describe the services provided for the user. The nonfunctional 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.
The structure of a requirements document
Chapter Description
System requirements specification
This should describe the functional and nonfunctional requirements in more detail. If necessary, further detail may also be added to the nonfunctional requirements. 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.
Chapter 4 Requirements engineering22
Users of a requirements document
Chapter 4 Requirements engineering23
Requirement SpecificationFormats
Natural Language
Structured natural language
Design Description language
Graphical
Mathmatical
Chapter 4 Requirements engineering24
Natural language specification
Natural language sentences supplemented by diagrams and tables.
Characteristics expressive, Intuitive universal
Chapter 4 Requirements engineering25
Guideline
Invent a standard format.
Consistent Language Shall vs. Should
Highlighting, Underlining.
Avoid computer jargon.
Include rationale for requirements
Example requirements for the insulin pump software
system
Chapter 4 Requirements engineering27
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 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.)
Structured specifications
Standard format
Predictable
Forces spec completion
May contain natural language
May be too rigid Standard sequence Tabular
Chapter 4 Requirements engineering28
A structured specification of a requirement for an
insulin pump
Chapter 4 Requirements engineering29
A structured specification of a requirement for an
insulin pump
Chapter 4 Requirements engineering30
Tabular specification of computation for an insulin
pump
Chapter 4 Requirements engineering31
Condition Action
Sugar level falling (r2 < r1) CompDose = 0
Sugar level stable (r2 = r1) CompDose = 0
Sugar level increasing and rate of increase decreasing ((r2 – r1) < (r1 – r0))
CompDose = 0
Sugar level increasing and rate of increase stable or increasing ((r2 – r1) ≥ (r1 – r0))
CompDose = round ((r2 – r1)/4)If rounded result = 0 then CompDose = MinimumDose
Requirements ElicitationProcess
Discovery
Classification/ Organization
Prioritization/ Negotiation
Documentation
Chapter 4 Requirements engineering32
Elicitation - Participants
Development personnel System engineers Developers Managers
Customer Managers Engineers, Domain experts Trade unions
Chapter 4 Requirements engineering33
Elicitation Problems
Stakeholders limited understanding of needs Assume basic knowledge of their domain Availability
Multiple stakeholders Different priorities Conflicting requirements
Which stakeholder Manager User
Changing business Generally Due to the system itself
Chapter 4 Requirements engineering34
Discovery Approaches
Interview
Scenario
Use Case
Ethnography
Chapter 4 Requirements engineering35
Types of Interviews
Types of interview Closed
list of questions Open
various issues explored.
Chapter 4 Requirements engineering36
Interviews in practice
Be prepared with questions
BUT, start with open ended questions
Bring up issues where you expect will cause problems
Scenarios
Real-life examples of how a system can be used.
Include description of the starting situation description of the normal flow of events description of what can go wrong Information about other concurrent activities description of the state when the scenario finishes
Scenario for collecting medical history in MHC-
PMS
Chapter 4 Requirements engineering39
Scenario for collecting medical history in MHC-
PMS
Chapter 4 Requirements engineering40
Use cases
UML Actors, Interaction
Should describe all possible interactions with the system.
Graphical or tabular
Chapter 4 Requirements engineering41
Use cases for the MHC-PMS
Chapter 4 Requirements engineering42
Ethnography
Based on interviews Watching people work Often < 1hr
Capture Interactions Activities Data Forms Pressures
Chapter 4 Requirements engineering43
Ethnography
Model the work environment Process flow Interactions Data Context
Chapter 4 Requirements engineering44
Ethnography
Useful for Understanding environment
People involved Current Processes Implicit environment Workflow Implicit aspects of work that people don’t explain Understanding without formal explanation
Shows that work is usually richer and more complex than suggested by simple system models.
Chapter 4 Requirements engineering45
Pros/Cons
Pros Actual work not concept Develops thorough knowledge of users, environment
Cons Focused only on existing process Focused only on needs of users
Chapter 4 Requirements engineering46
Focused ethnography
Combines ethnography with prototyping
Prototype can be evaluated in the work environment
Chapter 4 Requirements engineering47
Requirements checking
Validity. Does the system provide the functions which best support the customer’s needs?
Consistency. Are there any requirements conflicts?
Completeness. Are all functions required by the customer included?
Realism. Can the requirements be implemented given available budget and technology
Verifiability. Can the requirements be checked?
Chapter 4 Requirements engineering48
Requirements validation techniques
Requirements reviews Systematic manual analysis of the requirements.
Prototyping Using an executable model of the system to check
requirements. Covered in Chapter 2.
Test-case generation Developing tests for requirements to check
testability.
Chapter 4 Requirements engineering49
Requirements reviews
Regular
Client and contractor
Formal or informal
Chapter 4 Requirements engineering50
Review checks
Verifiability Is the requirement realistically testable?
Comprehensibility Is the requirement properly understood?
Traceability Is the origin of the requirement clearly stated?
Adaptability Can the requirement be changed without a large impact
on other requirements?
Chapter 4 Requirements engineering51
Requirements Management
Tracking changes to requirements New requirements Changed requirements Dropped Requirements
“Scope creep”
Chapter 4 Requirements engineering52
Requirements Management
Implicit part of agile development
Chapter 4 Requirements engineering53
Changing requirements
The business and technical environment of the system always changes after installation. New hardware necessary to interface the system with other systems business priorities change new legislation and regulations may be introduced Budgetary changes
The people who pay for a system and the users of that system are rarely the same people.
Chapter 4 Requirements engineering54
Changing requirements
Large systems usually have a diverse user community, with many users having different requirements and priorities that may be conflicting or contradictory. The final system requirements are inevitably a
compromise between them and, with experience, it is often discovered that the balance of support given to different users has to be changed.
Chapter 4 Requirements engineering55
top related