cs 425/625 software engineering software requirements
DESCRIPTION
CS 425/625 Software Engineering Software Requirements. Based on Chapter 6 of the textbook [SE-8] Ian Sommerville , Software Engineering, 8 th Ed., Addison-Wesley, 2006 and on Ch6 PowerPoint presentation from the book’s web-site October 12, 2009. Outline. Requirements: Functional - PowerPoint PPT PresentationTRANSCRIPT
1 / 26
CS 425/625 Software Engineering
Software Requirements
Based on Chapter 6 of the textbook [SE-8] Based on Chapter 6 of the textbook [SE-8] Ian Sommerville, Software Engineering, 8th Ed., Addison-Wesley, 2006
and on Ch6 PowerPoint presentation from the book’s web-site
October 12, 2009October 12, 2009
2 / 26
Outline
Requirements: Functional Non-functional Domain
User Requirements Systems Requirements The Software Requirements Document
3 / 26
Requirements: Introduction….
Requirements = services the system is expected to provide + constraints placed on the system
Requirements engineering = gathering, negotiating, analyzing, and documenting requirements
The requirements could be expressed at various levels of abstraction
The way requirements are defined has a major impact on the development of the software product
4 / 26
Requirements: .Introduction…
““If a company wishes to let a contract for a large softwareIf a company wishes to let a contract for a large softwaredevelopment project, it must define its needs in a sufficiently development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organisation’s offering, perhaps, different ways of meeting the client organisation’s needs. Once a contract has been awarded, the contractor must needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both client understands and can validate what the software will do. Both of these documents may be called the of these documents may be called the requirements documentrequirements document for for the system.” [Davis]the system.” [Davis]
5 / 26
Requirements: ..Introduction..
A classification of requirements: User requirements: higher level description of
services requested and constraints imposed System requirements: a more detailed, structured
description of services and constraints. Usually included in the contract between the developer and the client
An even more detailed description of requirements can be provided in a software design specification (closer to implementation)
6 / 26
Requirements: …Introduction. Examples of Examples of user requirementsuser requirements definitiondefinition and and system requirementssystem requirements
specificationspecification [Fig. 5.1, Sommerville 2000]. See also Fig. 6.1 [SE-8] [Fig. 5.1, Sommerville 2000]. See also Fig. 6.1 [SE-8]
1. The software must provide a means of representing and1. accessing external files created by other tools.
1.1 The user should be provided with facilities to define the type of1.2 external files.1.2 Each external file type may have an associated tool which may be1.2 applied to the file.1.3 Each external file type may be represented as a specific icon on1.2 the user’s display.1.4 Facilities should be provided for the icon representing an1.2 external file type to be defined by the user.1.5 When a user selects an icon representing an external file, the1.2 effect of that selection is to apply the tool associated with the type of1.2 the external file to the file represented by the selected icon.
Requirements definition
Requirements specification
7 / 26
Requirements: ….Introduction Types of software system requirements:
Functional requirements, describe the requested functionality/behaviour of the system: services (functions), reactions to inputs, exceptions, modes of operations
Non-functional requirements, represent constraints on the system and its functionality: performance constraints, compliance with standards, constraints on the development process
Domain requirements, can be either functional or non-functional and reflect the particularities of the application domain
8 / 26
Requirements: Functional Functional requirements:
Depend on the system, the software, and the users Can be expressed at different levels of detail
(user/system requirements) For a system, it is desirable to have a complete and
consistent set of functional requirements ● Completeness: all required system facilities are defined● Consistency: there are no contradictions in requirements
9 / 26
Requirements: Non-functional..
Non-functional requirements: Many apply to the system as a whole More critical than individual functional
requirements More difficult to verify
Kinds of non-functional requirements: Product requirements Organizational requirements External requirements
10 / 26
Requirements: .Non-functional. A classification of non-functional requirements [Fig. 6.3, SE-7]:
Performancerequirements
Spacerequir ements
Usabilityrequirements
Ef ficiencyrequirements
Reliabilityrequirements
Portabilityrequirements
Interoperabilityrequirements
Ethicalrequirements
Legislativerequirements
Implementationrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Productrequirements
Organizationalrequirements
Externalrequirements
Non-functionalrequirements
11 / 26
Requirements: ..Non-functional Metrics that can be used to quantitatively specify and verify
non-functional requirements [Fig. 6.6, SE-8]
Property 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
12 / 26
Requirements: Domain
Domain requirements indicate specific computations, additional functionality, or constraints on other requirements
Example [Fig.6.7, SE-8]:
The deceleration of the train shall be computed as:
Dtrain = Dcontrol + Dgradient
where Dgradient = 9.81ms2 * compensated gradient/alpha
and where the values of 9.81ms2/alpha are known for different types of train.
13 / 26
User Requirements…
User requirements: Should be understood by the user, and should not address
design and implementation aspects Should focus on the key facilities required
Problems with requirements written in natural language: Lack of clarity, ambiguity, various interpretations possible Confusion, lack of separation between different types of
requirements Mixture of several requirements in the same statement Hard to modularize and thus hard to find connections
between requirements
14 / 26
.User Requirements.. Example of improperly stated requirement [Fig. 6.9, SE-8]
2.6 2.6 Grid facilitiesGrid facilities
To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimetres or inches, via an option on the control panel. Initially, the grid is off. The grid may be turned on and off at any time during an editing session and can be toggled between inches and centimetres at any time. A grid option will be provided on the reduce-to-fit view but the number of grid lines shown will be reduced to avoid filling the smaller diagram with grid lines.
15 / 26
..User Requirements. Another example of requirements statement, well structured and
more precise [Fig. 6.10, SE-08]
16 / 26
…User Requirements
Guidelines for writing requirements: Create and use a standard format for the entire software
requirements specification Highlight important parts of the requirement statements Use consistently the language (difference between
“should” and “shall”) Avoid computer jargon
17 / 26
System Requirements……
System requirements: More detailed specifications of user requirements Included in the contract with the client Used by developers as basis for design May be specified using various models (object-oriented
models, data-flow diagrams, formal specs, etc.) Should indicate WHAT the system is required to do (not
HOW) and under what conditions and constraints
18 / 26
.System Requirements.….
There is nevertheless a blurred line between specification and design because: A system architecture may be needed to
structure the requirements specification Design constraints may be part of the system
requirements Factors such as interoperability may also
impose design constraints
19 / 26
..System Requirements…. Modalities for specifying requirements [Fig. 6.11, SE-8]:
Notation DescriptionStructurednaturallanguage
This approach depends on defining standard forms ortemplates to express the requirements specification.
Designdescriptionlanguages
This approach uses a language like a programming languagebut with more abstract features to specify the requirementsby defining an operational model of the system.
Graphicalnotations
A graphical language, supplemented by text annotations isused to define the functional requirements for the system.An early example of such a graphical language was SADT(Ross, 1977; Schoman and Ross, 1977). More recently, use-case descriptions (Jacobsen, Christerson et al., 1993) havebeen used. I discuss these in the following chapter.
Mathematicalspecifications
These are notations based on mathematical concepts suchas finite-state machines or sets. These unambiguousspecifications reduce the arguments between customer andcontractor about system functionality. However, mostcustomers don’t understand formal specifications and arereluctant to accept it as a system contract. I discuss formalspecification in Chapter 9.
20 / 26
…System Requirements…
Standard templates for structured natural language specification should include, as applicable: Description of the function/service Inputs and their sources Outputs and their destinations Dependencies (other elements required) Pre-conditions Post-conditions Side-effects
21 / 26
….System Requirements.. Example of a system requirement specified using structured natural
language [Fig. 5.13, Sommerville 2000] – see also [Fig 6.12, SE-8]
ECLIPSE/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
22 / 26
…..System Requirements.
Another alternative to natural language (NL) for software specification is Program Description Languages (PDL) Derived from programming languages May contain more abstract constructs Their syntax and semantics could be checked Recommended for describing sequences of actions
whose order is important & for specifying software interfaces
However, PDL specification require advised readers, can be taken as design specs, and may not be expressive enough
23 / 26
……System RequirementsExample of PDL requirements specification [Fig. 5.14, Somm2000],See also Fig. 6.15 [SE-7]
24 / 26
The Software Requirements Document..
This document, also called Software Requirements Specification (SRS), is the official description of the system’s requirements (includes user and system reqs.)
Heninger (1980) recommends that an SRS should: Specify only external system behaviour Specify constraints on implementation Be easy to change Serve as a reference for maintainers Record forethought about the software life cycle Describe acceptable responses to undesired events
25 / 26
.The System Requirements Document.
SRS structure according IEEE/ANSI 830-1993 standard (overview only, many more details are given in the standard): Introduction General description Specific requirements Appendices Index
This structure needs to be tailored for each particular organization
26 / 26
..The System Requirements Document..The System Requirements Document
A more detailed structure suggested in [Fig. 5.17, Somm00]: Table of contents Preface Introduction Glossary User requirements definition System architecture System requirements specification System models System evolution Appendices Index