Download - 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
![Page 1: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/1.jpg)
1
Software Requirements
Specifying system functionality and constraints
Chapters 5 and 6 ++
![Page 2: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/2.jpg)
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.
![Page 3: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/3.jpg)
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
![Page 4: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/4.jpg)
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
![Page 5: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/5.jpg)
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.
![Page 6: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/6.jpg)
6
Process activities Domain understanding
Requirements discovery or elicitation
Analysis and conflict resolution
Classification, Prioritization
Specification
Verification
![Page 7: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/7.jpg)
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.
![Page 8: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/8.jpg)
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
![Page 9: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/9.jpg)
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
![Page 10: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/10.jpg)
10
Methods of Discovery
Should use a well-defined methodical approach:
Introspection
Elicitation• Interviews
• Observation (Ethnography)
• Protocol Analysis
Viewpoint Oriented
Prototypes
![Page 11: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/11.jpg)
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
![Page 12: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/12.jpg)
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
![Page 13: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/13.jpg)
13
Specific Requirements (IEEE) Include functional, interface, performance, design
constraints, quality attributes, etc.
Each functional should include• overview
• inputs
• processing
• outputs
• exceptions
![Page 14: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/14.jpg)
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)
![Page 15: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/15.jpg)
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
![Page 16: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/16.jpg)
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
![Page 17: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/17.jpg)
17
The VORD process model Viewpoint identification
Viewpoint structuring
Viewpoint documentation
Viewpoint-system mapping
![Page 18: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/18.jpg)
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.
![Page 19: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/19.jpg)
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
![Page 20: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/20.jpg)
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
![Page 21: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/21.jpg)
21
Catalog management
Bookshop:Supplier
Cataloguer:Library Staff
Item:Library Item
Books:Catalog
Acquire New
Catalog Item
Uncatalog Item
Dispose
![Page 22: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/22.jpg)
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
![Page 23: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/23.jpg)
23
Usable Correct!
Understandable
Achievable
Design Independent
At Right Level of Detail
![Page 24: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/24.jpg)
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
![Page 25: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/25.jpg)
25
Well Structured Standard organization
Modifiable• Layout
• Limit Redundancy
Indexed (automated?)
![Page 26: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/26.jpg)
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
![Page 27: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/27.jpg)
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.
![Page 28: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/28.jpg)
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
![Page 29: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/29.jpg)
29
Annotated Appropriately by relative importance
• must, should, could
by relative stability
by version
![Page 30: 1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++](https://reader036.vdocuments.us/reader036/viewer/2022062314/56649f2b5503460f94c45753/html5/thumbnails/30.jpg)
30
Use Good Technical Writing Unambiguous
Concise
and so on …..