©ian sommerville 2000 software engineering. chapter 6 slide 1 chapter 6 software requirements
TRANSCRIPT
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 1
Chapter 6
Software Requirements
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 2
Objectives
To introduce the concepts of abstract “user” and more detailed “system” requirements.
To describe “functional” and “non-functional” requirements.
To explain two techniques for describing system requirements: structured NL and PDLs.
To suggest how software requirements may be organized in a requirements document.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 3
Requirements engineering (RE)
The process of eliciting, analyzing, docu-menting, and validating the services required of a system and the constraints under which it will operate and be developed.
Descriptions of these services and con-straints are the requirement specifications for the system.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 4
RE is both very hard and critical
The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult… No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.
– Fred Brooks, “No Silver Bullet…”
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 5
Why is RE so hard?
Difficulty of anticipation Unknown or conflicting requirements / priorities (“I’ll know what I want when I see it.”)
Conflicts between & among users and procurers Fragmented nature of requirements Complexity / number of distinct requirements
(More reasons in Chap. 6)
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 6
an·tic·i·pa·tion
noun, 14th century1. a prior action that takes into account or
forestalls a later action;2. the act of looking forward;3. visualization of a future event or state.
We can never know about the days to come, but we think about them anyway…Anticipation, anticipation is makin' me late, Is keepin' me waitin’. -Carly Simon
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 7
Why is RE so hard?
Difficulty of anticipation Unknown or conflicting requirements / priorities (“I’ll know what I want when I see it.”)
Conflicts between & among users and procurers Fragmented nature of requirements Complexity / number of distinct requirements
(More reasons in Chap. 6)
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 8
Why is RE so hard? (cont’d)
Some analogies: Working a dynamically changing jigsaw
puzzle Blind men describing an elephant Different medical specialists describing an
ill patient
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 9
Requirements uses
Requirements range from being high-level and abstract to detailed and mathematical.
Inevitable as requirements serve multiple uses... May be the basis for a bid for a contract – must be
open to interpretation; May be the basis for the contract itself – must be
defined in detail; May be the basis for design and implementation –
must bridge requirements engineering and design activities.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 10
Levels of requirements specification
“User requirements” – statements in natural language plus diagrams of system services and constraints. Written primarily for customers.
“System requirements” – structured document setting out detailed descriptions of services and constraints precisely. May serve as a contract between client and developer.
“Software design specification” – implementation oriented abstract description of software design which may utilize formal (mathematical) notations. Written for developers.
Terminology is a problem…
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 11
User vs. system requirements
1. The software must provide a means of repr esenting and1. accessing external fi les 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 repr esenting an1.2 external file type to be defined by the user.1 .5 When a user selects an icon repr esenting an external file, the1.2 effect of that selection is to apply the tool associated w ith the type of1.2 the external file to the file represented by the selected icon.
“User requirement”:
Corresponding “System requirements”:
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 12
Requirements readersClient managersSystem end-usersClient engineersContractor managersSystem architects
System end-usersClient engineersSystem architectsSoftware developers
Client engineers (perhaps)System architectsSoftware developers
User requirements
System requirements
Software designspecification
+ lawyers
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 13
“Functional, non-functional, and domain requirements”
“Functional requirements” – services the system should provide, how it should react to particular inputs, or how it should behave in particular situations.
“Non-functional requirements” – constraints on services or functions (e.g., response time) or constraints on development process (e.g., use of a particular CASE toolset).
“Domain requirements” – “functional or non-functional requirements” derived from application domain (e.g., legal requirements or physical laws).
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 14
Examples of “functional requirements”
The user shall be able to search either all of the initial set of databases or select a subset from it.
The system shall provide appropriate viewers for the user to read documents in the document store.
Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.
(Test of function: “We want the product to…” or “The product shall…”)
?
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 15
“Non-functional requirements”
Define system attributes (e.g., reliability, response time) and constraints (e.g., MTTF ≥ 5K transactions, response time ≤ 2 seconds). Attributes are often emergent system properties –
i.e., only observable when the entire system is operational.
Define process constraints (e.g., use of a particular CASE system, programming language, or development method).
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 16
“Non-functional requirements” are not second class requirements
“Non-functional requirements” may be more critical than “functional requirements.” If not met, the system may be useless.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 17
General non-functional classifications
“Product requirements” – specify product behavior.
“Organizational requirements” – derived from policies / procedures in customer’s or developer’s organization (e.g., process constraints).
“External requirements” – derived from factors external to the product and its development process (e.g., interoperability requirements, legislative requirements).
(Note: these are not orthogonal classifications)
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 18
General non-functional classifications (cont’d)
Performancerequirements
Spacerequirements
Usabilityrequirements
Efficiencyrequirements
Reliabilityrequirements
Portabilityrequirements
Interoperabilityrequirements
Ethicalrequirements
Legislativerequirements
Implementationrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Productrequirements
Organizationalrequirements
Externalrequirements
Non-functionalrequirements
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 19
Examples
“Product requirement”:4.C.8 It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character set.
“Organizational requirement”:9.3.2 The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95.
“External requirement”:7.6.5 The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.
APSE = Ada Programming Support Environment
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 20
“GOALS” vs. (verifiable) REQUIREMENTS
General goals such as “system should be user friendly” or “system should have fast response time” are not verifiable.
“Goals” should be translated into quantitative requirements that can be objectively tested.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 21
Example of system “GOAL” versus verifiable system REQUIREMENT
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 system 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 by experienced users shall not exceed two per day.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 22
Attribute 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
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 23
Requirements interactions Competing/conflicting requirements are common. Spacecraft system example:
To minimize weight, the number of chips in the unit should be minimized.
To minimize power consumption, low-power chips should be used.
But using low-power chips means that more chips have to be used.
For this reason, preferred points in the solution space should be identified.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 24
Preferred points in a solution space
Power Consumption
Weight
low high
low
high
Weight constraint
Power Consumption
constraint
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 25
Preferred points in a solution space
Power Consumption
Weight
low high
low
high
Weight constraint
Power Consumption
constraint
= feasible solutions
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 26
Preferred points in a solution space
Power Consumption
Weight
low high
preferred solutions
low
high
Weight constraint
Power Consumption
constraint
= feasible solutions
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 27
“Domain requirements”
Derived from the application domain rather than user needs.
May be functional or non-functional. If “domain requirements” are not satisfied, the
system may be unworkable.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 28
Train protection system domain requirement
The deceleration of the train shall be computed as:Dtrain = Dcontrol + Dgradient
where Dgradient is 9.81m/s2 * compensated gradient/alpha and where the values of 9.81m/s2
/alpha are known for different types of trains.
(physical law)
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 29
“Domain requirements” problems
Understandability – requirements are often expressed in the language of the application domain and may not be understood by software engineers.
Implicitness – domain experts may not communicate such requirements because they are so obvious (to the experts).
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 30
Requirements specification issues
Completeness and consistency problems
“User” vs. “system” requirements
Natural language vs. PDL’s vs. graphical representations
“Interface” vs. “operational” specifications
Specification requirements and “standards”
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 31
Requirements completeness and consistency
In principle, a requirements specification should be both complete and consistent. Complete – all required services and
constraints are defined. Consistent – no conflicts or contradictions
in the requirements. In practice, this is nearly impossible.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 32
“User requirements”
Understandable by system users who don’t have detailed technical knowledge.
Specify external system behavior (plus any user-specified implementation constraints.)
Utilize natural language, forms/tables, and simple, intuitive diagrams.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 33
Some potential problems with using natural language Ambiguity – requirements may be unclear or
may be interpreted in different ways. Consider the term “appropriate viewers” in:
“The system shall provide appropriate viewers for the user to read documents in the document store.”
Expressing requirements unambiguously is difficult without making documents wordy and hard to read.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 34
Mary had a little lamb.
Mary had a little lamb.
Mary had a little lamb.
Mary had a little lamb.
Mary had a little lamb.
Mary had a little lamb heuristic(From Gause & Weinberg, Quality Before Design)
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 35
Mary had a little lamb.
Mary owned a petite lamb.
Mary consumed a small amount of lamb.
Mary was involved with a young sheep.
Mary conned the trader.
Mary conned the trader heuristic(From Gause & Weinberg, Quality Before Design)
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 36
Some potential problems with using natural language (cont’d)
Requirements confusion – functions, constraints, goals, and design info may not be clearly distinguished.
Requirements amalgamation – several different requirements may be lumped together.
See illustrations on pp. 127-128.
Basic problem: need for different models of / perspectives on requirements.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 37
Guidelines for writing “user requirements”
Adopt a standard format and use it for all requirements.
Use language in a consistent way. E.g., use shall for mandatory requirements, should for desirable requirements.
Use text highlighting to emphasize key parts of the requirement.
Avoid the use of computer (and other types of) jargon.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 38
“System requirements”
More detailed, precise descriptions of user requirements.
May serve as the basis for a contract. Starting point for system design and
implementation. May utilize different system models such as
object or dataflow.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 39
“System requirements” and design information
System requirements normally state what the system should do, and not how it should be designed.
But some design info may be incorporated since: Sub-systems may be defined to help structure the
requirements. (Requirements may be grouped by sub-system.)
Interoperability requirements may constrain the design. Use of a specific design model may be a requirement.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 40
MORE potential problems with using natural language
Over-flexibility – the same requirement may (and probably should) be stated in a number of different ways. (Readers must determine when requirements are the same and when they are different.)
Lack of modularization – NL structures are inadequate to organize system requirements sufficiently.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 41
Alternatives to NL specificationNotation DescriptionStructurednaturallanguage
This approach depends on defining standard forms ortemplates to express the requirements specification.
Designdescriptionlanguages
This approach uses a language like a programminglanguage but with more abstract features to specify therequirements by defining an operational model of thesystem.
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)have been used. I discuss these in the following chapter.
Mathematicalspecifications
These are notations based on mathematical conceptssuch as finite-state machines or sets. These unambiguousspecifications reduce the arguments between customerand contractor 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.
“PDL’s”
10.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 42
Structured natural language form / template
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
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 43
Program Description Languages (PDLs)
Requirements are specified operationally using pseudo-code.
Shows what is required by illustrating how the requirements could be satisfied.
Especially useful when specifying a process that involves an ordered sequence of actions.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 44
Part of an ATM specification
class ATM {// declarations herepublic static void main (String args[]) throws InvalidCard {
try {thisCard.read () ; // may throw InvalidCard exceptionpin = KeyPad.readPin () ; attempts = 1 ;while ( !thisCard.pin.equals (pin) & attempts < 4 )
{ pin = KeyPad.readPin () ; attempts = attempts + 1 ;}if (!thisCard.pin.equals (pin))
throw new InvalidCard ("Bad PIN");thisBalance = thisCard.getBalance () ;do { Screen.prompt (" Please select a service ") ;
service = Screen.touchKey () ;switch (service) {
case Services.withdrawalWithReceipt:receiptRequired = true ;
JAVA based. Generic pseudocode is more abstract
and therefore easier to understand.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 45
PDL disadvantages PDL may not be sufficiently expressive to
illustrate requirements in a concise and understandable way.
Notation is only understandable to people with programming language knowledge.
The specification may be taken as a design prescription rather than a model to facilitate requirements understanding.
Can you think of ways to eliminate or mitigate these potential risks?
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 46
Graphical representations (See Chapter 8)
Graphical models are particularly useful in describing system environments (context models)
data structures and flows (semantic data models / dataflow diagrams)
state changes and system responses to events (state machine models)
classification and aggregation of system entities (object models)
dynamic system behavior (sequence models)
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 47
The context of an ATM system
Auto-tellersystem
Securitysystem
Maintenancesystem
Accountdatabase
Usagedatabase
Branchaccounting
system
Branchcountersystem
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 48
Graphical representations (See Chapter 8)
Graphical models are particularly useful in describing system environments (context models)
data structures and flows (semantic data models / dataflow diagrams)
state changes and system responses to events (state machine models)
classification and aggregation of system entities (object models)
dynamic system behavior (sequence models)
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 49
Library semantic model
Source
titlepublisherissuedatepages
1
Article
titleauthorspdf filefee
has-links
1
Buyer
nameaddresse-mailbilling info
places
fee-payable-to
n
1
n
published-in
delivers in
m n
1
1
1
CopyrightAgencynameaddress
Country
copyright formtax rate
1
Order
order numbertotal paymentdatetax status
in
1
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 50
Order processing DFD
Completeorder form
Orderdetails +
blankorder form
Validateorder
Recordorder
Send tosupplier
Adjustavailablebudget
Budgetfile
Ordersfile
Completedorder form
Signedorder form
Signedorder form
Checked andsigned order
+ ordernotification
Orderamount
+ accountdetails
Signedorder form
Orderdetails
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 51
Graphical representations (See Chapter 8)
Graphical models are particularly useful in describing system environments (context models)
data structures and flows (semantic data models / dataflow diagrams)
state changes and system responses to events (state machine models)
classification and aggregation of system entities (object models)
dynamic system behavior (sequence models)
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 52
Microwave oven model
Full power
Enabled
do: operateoven
Fullpower
Halfpower
Halfpower
Fullpower
Number
Dooropen
Doorclosed
Doorclosed
Dooropen
Start
do: set power= 600
Half powerdo: set power
= 300
Set time
do: get numberexit: set time
Disabled
Operation
Cancel
Waiting
do: displaytime
Waiting
do: displaytime
do: display 'Ready'
do: display'Waiting'
Timer
Timer
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 53
Graphical representations (See Chapter 8)
Graphical models are particularly useful in describing system environments (context models)
data structures and flows (semantic data models / dataflow diagrams)
state changes and system responses to events (state machine models)
classification and aggregation of system entities (object models)
dynamic system behavior (sequence models)
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 54
Library class hierarchy
Catalogue numberAcquisition dateCostTypeStatusNumber of copies
Library item
Acquire ()Catalogue ()Dispose ()Issue ()Return ()
AuthorEditionPublication dateISBN
Book
YearIssue
Magazine
DirectorDate of releaseDistributor
Film
VersionPlatform
Computerprogram
TitlePublisher
Published item
TitleMedium
Recorded item
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 55
Graphical representations (See Chapter 8)
Graphical models are particularly useful in describing system environments (context models)
data structures and flows (semantic data models / dataflow diagrams)
state changes and system responses to events (state machine models)
classification and aggregation of system entities (object models)
dynamic system behavior (sequence models)
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 56
Example: UML “Sequence diagrams”
These show the sequence of events that take place during some user interaction with a system.
You read them from top to bottom to see the order of the actions that take place.
Cash withdrawal from an ATM Validate card; Handle request; Complete transaction.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 57
“Sequence diagram” of ATM withdrawal
ATM Database
CardCard number
Card OKPIN request
PIN
Option menu
<<exception>>invalid card
Withdraw request
Amount request
Amount
Balance request
Balance
<<exception>>insufficient cash
Debit (amount)
Debit response
Card
Card removed
Cash
Cash removed
Receipt
Validate card
Handle request
Completetransaction
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 58
“Interface specifications”
Used to specify operating interfaces with other systems. Procedural interfaces (e.g., function, procedure, or method
names)
Data structures that are exchanged Data representations (if necessary)
Also used to specify functional behavior. Formal notations (e.g., pre- and post-conditions)
are effective.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 59
PDL-based interface description
interface PrintServer {
// defines an abstract printer server// requires: interface Printer, interface PrintDoc// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter
void initialize ( Printer p ) ;void print ( Printer p, PrintDoc d ) ;void displayPrintQueue ( Printer p ) ;void cancelPrintJob (Printer p, PrintDoc d) ;void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;
} //PrintServer
Method names and required parameters.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 60
“Interface specifications”
Used to specify operating interfaces with other systems. Procedural interfaces (e.g., function, procedure, or method
names)
Data structures that are exchanged Data representations (if necessary)
Also used to specify functional behavior. Formal notations (e.g., pre- and post-conditions)
are effective.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 61
Example: “interface” vs. “operational” specifications of a simple function
Function: Set BIG to the largest value in array A[1..N]
“interface specification”:
pre-condition: N ≥ 1
post-condition: there exists an i in [1,N] such that BIG=A[i] & for every j in [1,N], BIG ≥ A[j] & A is unchanged
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 62
Example: “interface” vs. “operational” specifications of a simple function
Function: Set BIG to the largest value in array A[1..N]
“operational specification”:
if N ≥ 1 then doBIG := A[1]for i = 2 to N do
if A[i] > BIG then BIG := A[i] end_ifend_for
end_if
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 63
The requirements document (SRS –
“Software Requirements Specification”)
Official statement of what is required of system developers.
Includes both user and system requirements. NOT a design document. As much as
possible, it should set out WHAT the system should do rather than HOW it should do it.
Users of an SRS
Use the requirements todevelop validation tests forthe system
Use the requirementsdocument to plan a bid forthe system and to plan thesystem development process
Use the requirements tounderstand what system is tobe developed
System testengineers
Managers
System engineers
Specify the requirements andread them to check that theymeet their needs. Theyspecify changes to therequirements
System customers
Use the requirements to helpunderstand the system andthe relationships between itsparts
Systemmaintenance
engineers
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 65
Requirements document requirements (Henniger ’80)
Should specify external system behavior. Should specify implementation constraints. Should be easy to change (!) Should serve as a reference tool for maintenance. Should include forethought about the life cycle of
the system (i.e., predicted changes). Should specify responses to unexpected events.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 66
IEEE requirements “standard*”
Generic Structure: Introduction General description Specific requirements Appendices Index
Instantiated for specific systems.
*IEEE Disclaimer: “This is not a standard…”
More detail in text. (p. 137)
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 67
Requirements document structure Preface (intended readers, version, change history) Introduction Glossary User requirements definition System architecture System requirements specification System models System evolution Appendices Index
An instantiated version of the IEEE model
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 68
Key points
Requirements set out what the system should do and define constraints on its operation and implementation.
“Functional requirements” set out services the system should provide
“Non-functional requirements” constrain the system being developed or the development process.
(cont’d)
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 69
Key points (cont’d)
“User requirements” are high-level statements of what the system should do.
They should be written in natural language, forms/tables, and diagrams.
(cont’d)
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 70
Key points (cont’d)
“System requirements” are intended to communicate the functions that the system should provide (more precisely than “user requirements”).
They should be written in structured natural language, a PDL, or in a formal language.
A software requirements document (SRS) is the agreed statement of a system’s requirements (both “User” and “System”).
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 71
A review of Sommerville’s classifications of requirements
“Functional” vs. “Non-Functional” Within the “Non-Functional” category:
“Product” vs. “Organizational” vs. “External” (3 different sources)
“Goals” vs. verifiable (non-functional) requirements “Domain requirements” (a 4th source; may be “functional” or
“non-functional”)
“User” vs. “System” vs. “Software Design Specification” (different levels and intended uses)
“Operational” vs. “Interface”
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 72
Chapter 6
Software Requirements