Download presentation
Presentation is loading. Please wait.
Published byEustace Golden Modified over 9 years ago
1
Chapter 4 Requirements Engineering Chapter 4 Requirements engineering1
2
Requirements Engineering May be used in all software Development models Waterfall Agile Reuse Other Chapter 4 Requirements engineering2
3
Requirements engineering processes Vary widely. Common processes Requirements elicitation; Requirements analysis; Requirements validation; Requirements management. Typically iterative/interleaved. Chapter 4 Requirements engineering3
4
Requirements Form Document (Traditional) Agreement (Agile) Chapter 4 Requirements engineering4
5
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
6
Levels of requirement User requirements High level For customers Their terminology System requirements Detailed For development For contacts Chapter 4 Requirements engineering6
7
User and system requirements Chapter 4 Requirements engineering7
8
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
9
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
10
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
11
Functional Requirement Challenge Lack of detail Lack of clarity Chapter 4 Requirements engineering11
12
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
13
Non-functional – Functional Link Non functional requirement may generate many functional requirements Security Logons Password recovery Chapter 4 Requirements engineering13
14
Types of nonfunctional requirement Chapter 4 Requirements engineering14
15
Measurability Non functional requirements must be measurable Chapter 4 Requirements engineering15
16
Metrics for specifying nonfunctional requirements Chapter 4 Requirements engineering16 PropertyMeasure SpeedProcessed transactions/second User/event response time Screen refresh time SizeMbytes Number of ROM chips Ease of useTraining time Number of help frames ReliabilityMean time to failure Probability of unavailability Rate of failure occurrence Availability RobustnessTime to restart after failure Percentage of events causing failure Probability of data corruption on failure PortabilityPercentage of target dependent statements Number of target systems
17
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
18
Domain requirements Operational environment Train brake control system Temperature range Humidity range Gradient range Chapter 4 Requirements engineering18
19
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
20
Agile methods and requirements Requirements Document Waste of Time Inherently out of date Replaced by user stories Chapter 4 Requirements engineering20
21
The structure of a requirements document Chapter 4 Requirements engineering21 ChapterDescription PrefaceThis 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. IntroductionThis 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. GlossaryThis 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 architectureThis 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.
22
The structure of a requirements document ChapterDescription 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 modelsThis 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 evolutionThis 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. AppendicesThese 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. IndexSeveral 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
23
Users of a requirements document Chapter 4 Requirements engineering23
24
Requirement Specification Formats Natural Language Structured natural language Design Description language Graphical Mathmatical Chapter 4 Requirements engineering24
25
Natural language specification Natural language sentences supplemented by diagrams and tables. Characteristics expressive, Intuitive universal Chapter 4 Requirements engineering25
26
Guideline Invent a standard format. Consistent Language Shall vs. Should Highlighting, Underlining. Avoid computer jargon. Include rationale for requirements
27
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.)
28
Structured specifications Standard format Predictable Forces spec completion May contain natural language May be too rigid Standard sequence Tabular Chapter 4 Requirements engineering28
29
A structured specification of a requirement for an insulin pump Chapter 4 Requirements engineering29
30
A structured specification of a requirement for an insulin pump Chapter 4 Requirements engineering30
31
Tabular specification of computation for an insulin pump Chapter 4 Requirements engineering31 ConditionAction 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
32
Requirements Elicitation Process Discovery Classification/ Organization Prioritization/ Negotiation Documentation Chapter 4 Requirements engineering32
33
Elicitation - Participants Development personnel System engineers Developers Managers Customer Managers Engineers, Domain experts Trade unions Chapter 4 Requirements engineering33
34
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
35
Discovery Approaches Interview Scenario Use Case Ethnography Chapter 4 Requirements engineering35
36
Types of Interviews Types of interview Closed list of questions Open various issues explored. Chapter 4 Requirements engineering36
37
Interviews in practice Be prepared with questions BUT, start with open ended questions Bring up issues where you expect will cause problems
38
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
39
Scenario for collecting medical history in MHC-PMS Chapter 4 Requirements engineering39
40
Scenario for collecting medical history in MHC-PMS Chapter 4 Requirements engineering40
41
Use cases UML Actors, Interaction Should describe all possible interactions with the system. Graphical or tabular Chapter 4 Requirements engineering41
42
Use cases for the MHC-PMS Chapter 4 Requirements engineering42
43
Ethnography Based on interviews Watching people work Often < 1hr Capture Interactions Activities Data Forms Pressures Chapter 4 Requirements engineering43
44
Ethnography Model the work environment Process flow Interactions Data Context Chapter 4 Requirements engineering44
45
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
46
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
47
Focused ethnography Combines ethnography with prototyping Prototype can be evaluated in the work environment Chapter 4 Requirements engineering47
48
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
49
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
50
Requirements reviews Regular Client and contractor Formal or informal Chapter 4 Requirements engineering50
51
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
52
Requirements Management Tracking changes to requirements New requirements Changed requirements Dropped Requirements “Scope creep” Chapter 4 Requirements engineering52
53
Requirements Management Implicit part of agile development Chapter 4 Requirements engineering53
54
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
55
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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.