2
Requirements engineering Requirements engineering (or requirements analysis)
is the process of establishing:• the services that the customer requires from a system• the constraints under which it operates and is developed
A requirement may range from a high-level abstract statement of a service or constraint to a detailed mathematical expression
Failure here is a major cause of software development failures.
3
Types of requirements User requirements
• statements in natural language plus diagrams• written for customers
System requirements• detailed, structured descriptions of system services• written as a contract between client and contractor
Software design specification• even more detail – can serve as a basis for a design• written for developers
4
Requirement classification
Functional requirements• statements of services the system should provide• they describe how the system should react to particular
inputs and how it should behave in particular situations• might include user interface issues
Constraints• constraints on the services offered by the system• timing constraints, standards, development processes
5
Functional requirements examples The user shall be able to search either all of the initial set of
databases or select a subset from that set to search.
The system shall provide the viewers listed in Appendix B: Supported Viewer Software, for the user to read documents in the document store.
Every order shall be allocated a unique identifier which the user shall be able to copy to the account’s permanent storage area.
6
Process activities Domain understanding
Requirements discovery or elicitation
Analysis and conflict resolution
Classification, Prioritization
Specification
Verification
7
Requirements Discovery Involves technical staff working with customers to
find out about the application domain, the services that the system should provide and the system’s operational constraints
May involve various stakeholders: end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc.
8
Why is it difficult? Client doesn’t know what they really want
Client underestimates importance
Client makes assumptions
Producer not familiar with application area
Different stakeholders may have conflicting requirements
Difficult client/producer chemistry
The requirements change during the analysis process
9
Be wary of runaway requirements Do not allow scope creep
Be aware of “kitchen sink” user approach
Elicit justification of requirements
Reject if not plausible or cost/benefit high
10
Methods of Discovery
Should use a well-defined methodical approach:
Introspection
Elicitation• Interviews
• Observation (Ethnography)
• Protocol Analysis
Viewpoint Oriented
Prototypes
11
The requirements document The requirements document is the official statement of
what is required of the system developers
It is read by a variety of stakeholders (people interested in the system and its development)
It is not a design document
As much as possible, it should specify what the system should do rather than how it should do it
12
IEEE requirements standard Defines a generic structure for a requirements
specification:• Introduction
• Purpose, Scope, Definitions, References, Overview
• General description• Perspective, Functions, User, Constraints
• Specific requirements
• Appendices
• Index
13
Specific Requirements (IEEE) Include functional, interface, performance, design
constraints, quality attributes, etc.
Each functional should include• overview
• inputs
• processing
• outputs
• exceptions
14
Alternatives to natural language Structured natural language
• standard templates
Program design language (PDL)• like a programming language, but more abstract
Graphical notation• diagrams with text annotations
Mathematical specification• formal and precise (ex: finite state machine)
15
Form-based specificationECLIPSE/Workstation/Tools/DE/FS/3.5.1
Function Add node
Description Adds a node to an existing design. The user selects the type of node, and its position.When added to the design, the node becomes the current selection. The user chooses the node position bymoving the cursor to the area where the node is added.
Inputs Node type, Node position, Design identifier.
Source Node type and Node position are input by the user, Design identifier from the database.
Outputs Design identifier.
Destination The design database. The design is committed to the database on completion of theoperation.
Requires Design graph rooted at input design identifier.
Pre-condition The design is open and displayed on the user's screen.
Post-condition The design is unchanged apart from the addition of a node of the specified typeat the given position.
Side-effects None
Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1
16
Structured presentation
2.6 Grid facilities2.6.1 The editor shall provide a grid facility where a
matrix of horizontal and vertical lines provide abackground to the editor window. T his grid shall bea p assive grid where the alignment of entities is theuser's responsibility.Rationale: A grid helps the user to create a tidydiagram with well-spaced entities. Although an activegrid, where entities 'snap-to' grid lines can be useful,the positioning is imprecise. The user is the best personto decide where entities should be positioned.
Specification: ECLIPSE/WS/Tools/DE/FS Section 5.6
17
The VORD process model Viewpoint identification
Viewpoint structuring
Viewpoint documentation
Viewpoint-system mapping
18
Scenarios Scenarios are descriptions of how a system is used in
practice
They are helpful in requirements elicitation as people can relate to these more readily than abstract statement of what they require from a system
Scenarios can be included in a user oriented requirements document.
19
Scenario descriptions The description of a scenario includes:
• System state at the beginning of the scenario
• Normal flow of events in the scenario
• What can go wrong and how this is handled
• Other concurrent activities
• System state on completion of the scenario
20
Use cases Use cases are a scenario-based technique in 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
Sequence diagrams may be used to add detail to use cases by showing the sequence of event processing in the system
21
Catalog management
Bookshop:Supplier
Cataloguer:Library Staff
Item:Library Item
Books:Catalog
Acquire New
Catalog Item
Uncatalog Item
Dispose
22
Desirable Properties of the SRSand of requirements themselves
Usable
Complete and Consistent
Well structured
Traceable and Verifiable
Annotated in appropriate ways
Good technical writing used
24
Complete and Consistent
In principle requirements should be both complete and consistent
Complete – they should include descriptions of all facilities required
Consistent – there should be no conflicts or contradictions in the descriptions
In practice, for large systems, it is almost impossible to produce a complete and consistent requirements document
26
Traceable
Traceability is concerned with the relationships between requirements, their sources and the design
Source traceability• Links from requirements to stakeholders who proposed these
requirements
Requirements traceability• Links between dependent requirements
Design traceability• Design Document can reference the requirements separately
27
Verifiable Goals can be fuzzy. Requirements should not be. There should
exist a finite, cost-effective way to check each one. A system goal
• The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized.
A verifiable non-functional requirement• Experienced controllers shall be able to use all the system functions
after a total of two hours training. After this training, the average number of errors made shall not exceed two per day.
Defining verifiable requirements can be difficult.
28
Requirements measuresProperty MeasureSpeed Processed transactions/second
User/Event response timeScreen refresh time
Size K BytesNumber of RAM 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
29
Annotated Appropriately by relative importance
• must, should, could
by relative stability
by version
Top Related