requirements management with use cases module 7: refine the system definition requirements...

Requirements Management with Use Cases

Module 7: Refine the System Definition

Requirements Management with Use Cases

Module 7: Refine the System Definition

Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 2

Where Are We in The Requirements Workflow?


Refine the System Definition: Module Objectives

Decide on the detailed software requirements Define the Software Requirements Specification Detail the use cases Detail the declarative requirements Learn qualities of good requirements


Refine the System Definition: Activities and Artifacts


Refine the System: Software Requirements Focus

Problem

Solution Space

Problem Space

Needs

Features

SoftwareRequirements

Test Procedures Design User

Docs

The The Product Product To Be To Be BuiltBuilt

Traceability


What Do Software Requirements Specify?

SystemInputs Outputs

Functions

Performance

Environments


Features Drive Software Requirements

Feat 63 - the defect tracking system will provide trending information to help the project manager assess project status

Trending information will be charted with a line graph showing time on the x axis, and number of defects found on the y axis.

Trending periods can be entered in units of days, weeks or months.

An example trend reportis shown in Figure 1:

Print StatusReport

Operator ProjectManager


Specifying the Software Requirements

Features

SoftwareRequirements

Needs

The Software Requirements Specification (SRS) package defines complete external behavior and characteristics of the system to be built

Vision Document

Vision Document

Supplementary Specifications

Supplementary SpecificationsUse-Case Model

SRS SRS Package


Roles of the SRS Package

Basis of communication between all parties Contractual agreement between parties Basis for development: design, implement, test

Supplementary Specifications

Supplementary SpecificationsUse-Case Model

SRS SRS Package


Who Uses the SRS Package? Client team

Customer: approve what system should do Users: understand what system should do

Developer team Use-case and requirements specifiers:

refine software requirements Designers: find design classes Testers: use as basis for test cases Project Manager: manage the project Technical Writers: write user’s guide

Remember the SRS is for people to read, not for computers


1. Introduction1.1 Purpose1.2 Scope1.3 Definitions, Acronyms, and Abbreviations1.4 References1.5 Overview

2. Overall Description2.1 Use-Case Model Survey2.2 Assumptions and Dependencies

3. Specific Requirements3.1 Use Case Reports

3.1.1 <Use Case 1>3.1.2 ...

3.2 Supplementary Specifications3.2.1 Usability Requirements3.2.2 …

4. Supporting InformationAppendicesIndex

1. Introduction1.1 Purpose1.2 Scope1.3 Definitions, Acronyms, and Abbreviations1.4 References1.5 Overview

2. Overall Description2.1 Use-Case Model Survey2.2 Assumptions and Dependencies

3. Specific Requirements3.1 Use Case Reports

3.1.1 <Use Case 1>3.1.2 ...

3.2 Supplementary Specifications3.2.1 Usability Requirements3.2.2 …

4. Supporting InformationAppendicesIndex

What Is In An SRS Package?

TP7:SRS Package Template


Documents

ProjectRepository

Where to Store The Items in The SRS Package?

The mechanics of where to store depend onAvailable toolsDeveloper environment and preferencesClient environment and preferences


How to Specify Functional Requirements ?

Use Cases

Use Cases

Declarative Statements

The system shall … The system shall … The system shall ...


?Which one to choose?


How to Specify Functional Requirements ? Recommendation

Use Both Use Cases and Declarative Statements• Both are necessary to understand any system of significant complexity

Preference for uses cases, where appropriate

Use Cases

Use Cases



The system shall … The system shall … The system shall ...+


SRS Variations For Functional Requirements

Use CasesDeclarative Statements Use Cases


Situation 1 Situation 2

The system …

The system …

The system …

The system … The system …

The system …


The system …



Specifying Software Requirements in Use Cases

Each use case Describes actions the system takes to deliver something

of value to the actor Shows the system functionality that an actor uses Models a dialogue between the system and actors Is a complete and meaningful flow of events, from the

perspective of a particular actor

Use-Case Model


<Use-Case Name>*

1. Brief Description*

2. Flow of Events*

Basic Flow of Events

Alternative Flows of Events

3. Special Requirements4. Pre-Conditions

5. Post-Conditions

6. Extension Points

7. Relationships*

8. Use-Case Diagrams

9. Other Diagrams/enclosures

<Use-Case Name>*

1. Brief Description*

2. Flow of Events*

Basic Flow of Events

Alternative Flows of Events

3. Special Requirements4. Pre-Conditions

5. Post-Conditions

6. Extension Points

7. Relationships*

8. Use-Case Diagrams

9. Other Diagrams/enclosures

Use-Case Report: Template

The Use-Case Report contains detailed information about an individual use case

TP5: Use Case Report Template


Use-Case Properties in the Use-Case Report

Name (same as in Use-Case-Model Survey) Brief description (same as in Use-Case-Model Survey) Flow of events

The use case’s behavior What the actors do, what the system does in response

Special requirements Requirements about this use case not covered in flow of events Usually non-functional requirements

Pre-conditions Constraints on when the use case may start

Post-conditions Constraints on the system after the use case has ended


Use-Case Properties in the Use-Case Report (cont.)

Extension points Places in the flow of events to attach extensions

Relationships (same as in Use-Case-Model Survey) Associations with actors and with other use cases

Use-Case diagrams Visual model of all relationships involving this use case

Other Diagrams or enclosures Interaction, activity, or other diagrams Pictures of the user interface


Sample Basic Flow of EventsWithdraw Cash Use Case

1. Insert Bank CardThis use case begins when the Bank Customer inserts a bank card in the card reader on the ATM machine. The ATM validates the card.

2. Enter PINThe ATM asks for the customer PIN code. The Bank Customer enters the PIN code.

3 Select ‘Withdraw Cash’The ATM displays the different alternatives that are available on this unit. The Bank Customer selects “Withdraw Cash”.


Sample Basic Flow of Events (cont.)4. Enter Account and Amount

The ATM asks for account to withdraw from and amount to withdraw. The Bank Customer enters account and amount.

5. Debit Bank AccountThe ATM sends the card id, PIN, amount and account to the Bank Consortium. The Bank Consortium replies that the transaction is accepted. The ATM system reports to the Bank Customer that it is ready to dispense cash.

6. Print ReceiptThe ATM asks the Bank Customer if a receipt is desired. The Bank Customer requests a receipt. The ATM system prints the receipt.

7. Receive Cash and CardThe ATM system dispenses money to the Bank Customer, and returns the Bank Card. The use case ends.


Sample Alternative Flows of Events

A1. Bank Card Not ValidIf in Step 1, Insert Bank Card, the card is not valid, it is ejected to the Bank Customer with a "sorry not a valid card" message. The use case ends.A2. Wrong PINIf in Step 5, Debit Bank Account , the Bank Consortium reply indicates a wrong PIN. The message "wrong PIN" is shown to the Bank Customer. The Bank Customer has three tries to get it right. If the Bank Customer correctly enters the PIN, the basic flow resumes at Step 4, Enter Account and Amount. Otherwise the card is kept by the ATM machine and the use case ends.

What other alternatives can you think of?


Exercise: Choosing a Style for the Flow of Events

Read the different flow of events descriptions on the following three (3) slides and answer the following questions:

Who is the intended audience?

Which is the easiest to understand (read)?

Which do you think is the easiest to write?

Is any one “better” than the others?

Which one do you prefer? Why?


Flow of Events - Style Type I

Orderers can create Orders to collect measurement data from Network Elements.

The system will assign the Order a unique name and default values for when and how long the measurement should be and also how often it is to be repeated. These values can of course be edited by the Orderer.

The Orderer must further specify which measurement function, network element and measurement objects to apply. The Orderer can also add a personal comment to the order.

When necessary information is defined, a new Order is created and initialized with the defined attributes, the name of the creator, date of creation, and status of the order will be set to 'scheduled'. (Possible values for the status are: Scheduled, Executing, Completed, Canceled, and Erroneous).

The Operator is then notified that a new Order has been created and receives a reference to the new Order so that it can be displayed.


1. Request a Measurement Order This use case starts when the Operator requests a Measurement

Order. The system displays all available Network Elements that the operator has the authority to access.

2. Configure Network Elements• The operator selects which network elements to measure, and chooses

measurement objects and functions for each selected network element. • The operator indicates he is finished configuring network elements.

3. Specify Measurements• The system give the measurement order a unique name and displays

default values for when, how often, and for how long the measurements should be made. The operator edits the default values as needed.

• The operator optionally enters a comment on the order.

4. Create Measurement Order The operator requests the system to create the measurement order.

The system confirms creation of the measurement order with the operator and provides a reference to it. The use case ends.

Flow of Events - Style Type II


Flow of Events - Style Type III=> 'Administrator order' (User identity)REPEAT

<='Show administrator order menu'IF (=> 'Creating an Order' (Measurement function,

network element, measurement object)) THENThe system finds a unique name, default values for when, how often and for how long the measurement should be executed.<= 'Show order' (Default attributes)REPEAT

=> 'Edit order' (Attribute to change, New value of attribute)<= 'Update screen' (New attributes)

UNTIL (All attributes are defined)REPEAT

IF (=> 'Edit order' (Attribute to change, New value of attribute)) THEN <= 'Update screen' (New attributes)ELSIF (=> 'Save order' (Order identity, Attributes)) THEN

The order is created and initialized in the system with the defined attributes, the name of the creator, date of creation and the status 'scheduled'.)

ENDIFUNTIL (=> 'Quit')

ENDIFUNTIL 'Quit administrator order'


Exercise: Perspectives in Flow of Events

Now, read the different flow of events descriptions on the following two (2) slides and answer the following questions: Who is the intended audience?

Which is the easiest to understand (read)?

Which do you think is the easiest to write?

Is one “better” than the other?

Which one do you prefer? Why?


Outside Perspective

Flow of Events

1. The use case starts when the subscriber lifts the phone, and gets a dial tone.

2. The dial tone disappears when the subscriber dials the first digit.

3. The subscriber dials the rest of the number and will then hear a ring tone if the called party is not busy.

4. The ring tone will disappear if the called party answers the phone call.

5. The call continues until both parties hang up their phones.

6. If the called party is busy the subscriber will hear a busy tone and will then hang up the phone.

Local Call

Subscriber


Inside Perspective

Flow of Events

1. The use case is initiated when the subscriber lifts the phone and the system finds the correct subscriber object, marks it busy and gives a dial tone to the subscriber.

2. The system turns off the dial tone when the subscriber dials the first digit. The system loads the digit into a register and will then wait to receive and store the rest of the digits.

3. When the system has received enough digits it will start to analyze the received digits.

4. When the whole number has been analyzed the system will find the corresponding subscriber object and check whether or not it is marked busy.

5. If the called party is not busy the system will busy mark the object and start ...

Local CallSubscriber


How to Refine a Use Case Flow of Events Gradually add detail to the step-by-step outline

Work together with users to refine the outline

• Include all events in the outline• Sketch outlines on large paper• Expect to revise the outline many times

First refine the Basic Flow of Events

• What normally happens Then refine the Alternative Flows


Questions To Help Detail The Flow of Events Sequence

What event starts the use case? How does the use case end? How does the use case repeat some behavior? Are there optional situations in the use case?

Action What does each actor do? What does the system do?

Interaction How does the use case interact with actors? What data is exchanged with actors?


What does NOT belong in the Flow of Events? Do NOT describe

Events outside the use case• In other use cases• Between an actor and others outside the system

System operations not visible externally Details of the user interface

• Unless it is an important requirement

Avoid vague terminology Such as “for example”, “etc. ” and “information”


Guidelines For Refining the Basic Flow of Events Structure the basic flow into steps Give each step a number and/or a title Describe each step in 1-3 sentences Make each step a roundtrip of events

What the Actor does:

• When the <Actor> requests <System> to ... What the System does in response:

• <System> sends message to <Actor> and ...


Exercise: Detail the Basic Flow of Events

Describe each step in the basic flow of events for one or more use cases in your project Start with the step-by-step outlines written for your use

case model (in Unit 5) Give each step a title Describe each step in more detail: add 1 to 3 sentences Focus only on the normal “happy day” path through the

use case. No alternative flows, yet! Write neatly so that you can copy and distribute the text

to the rest of the group


Why Divide a Flow of Events into Alternative Flows? Keep basic flow short and easy to read

Isolate optional sequences• Variant events• Optional events

• Exceptions and errors Isolate sequences executed

several times in same flow Clarify traceability


How to Refine The Alternative Flows

Use one section for each alternative flow Give each alternative flow a number and title Divide into steps only if it helps clarify

Describe what happens in the alternative flow Where in the basic flow or another subflow the

alternative flow starts The condition for doing the alternative flow Behavior within the alternative flow Where basic flow or another subflow is resumed

Describe the order of the alternative flows Only describe order of flows as fixed, if it is In other cases, point out that the order is unfixed


Specific Alternative Flows

Occur at a specific step in another flow Example

A3. Not Enough Money in Account

If the Bank Consortium finds that there is not enough money in the Bank Customer’s bank account, the ATM sends the Bank Customer an error message "Sorry not enough money”. The Bank Customer has an opportunity to enter a new account and amount.


Specific Alternative Flows Should make clear references

Where you pick up the sequence of actions Where you hand it over to another flow

Previous example, with clearer references A3. Not Enough Money in Account

In Step 5, Debit the Account, of the basic flow, if the Bank Consortium replies to the ATM that there is not enough money in the Bank Customer’s bank account, the ATM sends the Bank Customer an error message "Sorry not enough money”. The ATM continues at Step 4, Enter Account and Amount, of the basic flow.


General Alternative Flows

Occur anywhere in another flow Example

A4: Quit

The ATM will allow the Bank Customer to quit at any time during the use case. The ATM will stop the transaction, log the transaction, and eject the Bank Card. The use case ends.


Another Example: Alternative Flows of EventsBasic Flow of Events1. Request a Measurement Order

This use case starts when the Operator requests a Measurement Order. …2. Configure Network Elements

The operator selects which network elements to measure, and chooses ... 3. Specify Measurements

The system give the measurement order a unique name and displays …3. Create Order

The operator requests the system to create the measurement order. ...

Alternative Flows of EventsA1. No Network Elements Available

If, in Step 1, no Network Elements are available to measure for this Operator, the system will inform the operator. The use case then ends.

A2. No Measurement Functions AvailableIf, in Step 2, no measurement functions are available for the selected network elements, the Operator may select other Network elements.

A3. Cancel Measurement OrderThe system will allow the Operator to cancel all actions at any point during the use case. The system will delete the Order and then end the use case.


Exercise: Detail the Alternative Flows Further detail at least three (3) alternative flows

for each use case in the previous exercise Continue the description of the flow of events of the use

cases in your class project Use the alternatives identified in the step-by-step

outlines written for your use cases (in Module 5) Describe clearly what will happen in each alternative Write neatly so that you can copy and distribute the text

to the rest of the group


Using pre- and post-conditions Pre- and post-conditions are observable to the user Use only if needed for clarification

A pre-condition Constraint on when use case can start NOT the event that starts the use case

A post-condition Guaranteed true when use case ends Should apply regardless of

alternative flows May contain different variants

Pre- and Post-Conditions


Example of a Pre-Condition

Withdraw Cash

Pre-condition The customer has a personally-issued card that fits in the

card reader, has been issued a PIN number, and is registered with the banking system.

Use only if needed for clarification!


Example of a Post-Condition

Withdraw Cash

Post-condition At the end of the use case, all account and transaction

logs are balanced, communication with the banking system is reinitialized, and the customer has been returned his card or informed of where it will be sent.

Use only if needed for clarification!


What About Requirements NOT in Use Cases?

Use a declarative statement to describe the software requirement

Number and title each requirement Group related requirements for understandability Use language users can easily understand

Use simple sentence structure: subject + active verb Consider using a keyword, for example “shall” Keep it short: state a requirement in 1 to 3 sentences Use terms from the glossary


Where Are Declarative Requirements Specified? Does requirement apply to a particular use case?

Specify in the use case report In “Special Requirements” property

Does requirement apply to the whole system? Specify in the “Supplementary Specifications”

TP6: Supplementary Specifications Template


Functional Requirements in Declarative Statements

Some functionality is easier to state declaratively Example: ATM System

1. Internationalization

The ATM system shall display all messages and menus in the user’s preferred language.


What about Non-Functional Requirements? The “URPS” of FURPS

Usability Reliability Performance Supportability

Compliance with Legal and Regulatory requirements FCC FDA DOD ISO

Design Constraints Operating systems Environments Compatibility Application standards

What are some others?


A Closer Look at the “URPS” of FURPS

Grady, 1992

Functionality Feature SetCapabilities

GeneralitySecurity

Usability Human FactorsAesthetics

ConsistencyDocumentation

Reliability Frequency/Severityof FailureRecoverability

PredictabilityAccuracyMTBF

Performance SpeedEfficiencyResource Usage

ThroughputResponse Time

Supportability TestabilityExtensibilityAdaptabilityMaintainabilityCompatibility

ConfigurabilityServiceabilityInstallabilityLocalizabilityRobustness


Examples: Non-Functional Requirements

The ATM System The system can only handle one customer at a time. The system has to be available 24 hours a day, 7 days

a week, with less than .01% downtime.

What are some others?Where should each of these be specified?


Specifying Usability Requirements Definition of “usability”

The ease with which software can be learned and operated by the intended users

Usability requirements Training time requirements, measurable task times User abilities (unsophisticated/sophisticated) Comparison to other systems that users know and like On-line help systems, tool tips, documentation needs Conformity with standards

• Examples: Windows, style guides, GUI Standards


Davis Workshop, 1993

Specifying Reliability Requirements Definition of “reliability”

The ability for the software to behave consistently in a user-acceptable manner

Reliability requirements Availability (xx.xx%) Accuracy Mean time between failures (xx hrs) Max. bugs per/KLOC (0-x) Bugs by class - critical, significant, minor

Reliability predictors Lines of code Complexity metrics



Specifying Performance Requirements Definition of “performance”

A measure of speed or efficiency of the running system Performance requirements

Capacity Throughput Response time Memory Degradation modes Efficient use of scarce resources

• Processor, memory, disk, network bandwidth



Specifying Supportability Requirements

Definition of “supportability” The ability of the software to be easily modified to

accommodate enhancements and repairs Supportability requirements

Languages, DBMS, tools, etc. Programming standards Error handling and reporting standards

If not observable, state as intent or goals If not measurable or observable, it is not a requirement


Find what

R eplace w ith

R eplace

Start C ancel

How to Describe User Interfaces

Enclose sketches of proposed screen appearance with the use-case descriptions

Be careful not to specify too much of the design in the use-case documents


How to Describe Communication Protocols

Specify a communication protocol if the actor is another system or external hardware The description of the use case should state if some

existing protocol is to be used If the protocol is new, it will be fully described during

object-model development


What About Design Constraints?

A requirement allows more than 1 design option A design is a choice among options

A requirement that leaves no options is a design constraint Distinguish it from other requirements Place in a special section of your software requirements Identify the source of each Document the rationale for each

Examples An algorithm that is required to be used A database system that is required to be used


WhatHow

WhatHow

WhatHow

Stakeholder Needs

Product or System Features

Software Requirements Specification (Use Cases)

Design Spec Test Procedures Documentation Plans

“One man’s

ceiling is

another man’s floor”

Davis, 1993

The What vs. How DilemmaQuestion: How can you tell a requirement from design?

Answer: It depends on your point of view.


Exercise: Non-Functional Requirements

For your class project, list at least 5 non-functional requirements

Decide where each non-functional requirement should be specified1. In the properties of a particular use case

• Special Requirements• Basic flow• Alternative flows

2. In the Supplementary Specifications


ref - IEEE 1993

Qualities of a Software Requirement Specification

Correct Complete Consistent Unambiguous Ranked for importance and stability Verifiable Modifiable Traceable Understandable


Qualities of an SRS: Correct

A Requirements Specification is “correct” if: Every requirement within it is something required of the

system to be built For example, every requirement in the SRS contributes

to the satisfaction of some need

Hint: Involve the people who have the problem or mission

ref - Davis ‘93


IEEE 1993

Qualities of an SRS: Complete

A Requirement Specification is “complete” if it contains: All significant requirements Responses of the software to all inputs Full labels and references to figures, tables, diagrams Definitions of all terms and units of measure

(Glossary / Data Dictionary)


A Requirements Specification is “consistent” if: Individual requirements described in it do not conflict

Hint: Trace all related requirements

IEEE 1993

SR101: The power LED shall be illuminated whenever the machine is on.

SR841: When the on-button is pressed, no observable results shall occur.

Qualities of an SRS: Consistent

SR245: When the on-button is pressed, the system shall illuminate the power LED.

(Inconsistent)(Consistent)


ref - IEEE 1993

“A shall do B to C”



Req. 1

Qualities of an SRS: Unambiguous

A Requirements Specification is “unambiguous” if: Every requirement within it has only one interpretation


Exercise: Exploring Ambiguity

Mary had a little lamb.In the space below, write (or draw) two interpretations of what this sentence means.

ref - Gause & Weinberg, 1989


Exploring Ambiguity: Dictionary Definitionshad - past of havehave - 1a: to hold in possession as property 4a: to acquire or get possession of: OBTAIN (best to be had) c: ACCEPT; to have in marriage 5a: to be marked or characterized by (have red hair) 10a: to hold in a position of disadvantage or certain defeat b: TRICK, FOOL (been had by a partner) 12: BEGET, BEAR (have a baby) 13: to partake of (have dinner) 14: BRIBE, SUBORN (can be had for a price)lamb - 1a: a young sheep esp. less than one year old or without

permanent teeth b: the young of various other animals (as smaller antelopes) 2a: a person as gentle or weak as a lamb b: DEAR, PET c: a person easily cheated or deceived especially in trading

securities 3a: the flesh of lamb used as food


Exploring Ambiguity: Analysis

have lamb Interpretation1a 1a Mary owned a little sheep under one year of age or

without permanent teeth.4a 1a Mary acquired a little sheep under one year of age or

without permanent teeth.5a 1a Mary is the person who owned a little sheep under

one year of age or without permanent teeth.10a 1a Mary held a little sheep under one year of age or

without permanent teeth in a position of disadvantage.

10b 1a Mary tricked a little sheep under one year of age or without permanent teeth.

12 1b Mary gave birth to a young antelope.12 2a Mary is (or was) the mother of a particular small, gentle

person.13 3a Mary ate a little of the flesh of lamb.14 2c Mary bribed a small person trading in securities who

was easily cheated.


Gause & Weinberg, 1989

What to Do About Language Ambiguity The Ambiguity Poll - create a measure that requires a

solid understanding of the problem to estimate. Memorization Heuristic - get various individuals to try to

recall the problem statement from memory. Parts that are not clear are likely the most ambiguous.

Key Word Technique - determine the key operational words in the statement and list their definitions. Mix and match to determine different interpretations. (Use these terms for glossary.)

Emphasis Technique - emphasize different words until as many interpretations as possible are discovered.

Other Techniques - use other techniques, pictures, graphics, formal methods -- that’s what use cases are for!


Exploring Ambiguity: An Observation

Techniques that reduce ambiguity in an SRS often decrease understandability and alienate customers and users.

Our goal is to find the “sweet spot” where we attain the greatest understandability with the least ambiguity

Understandability

Ambiguity

The sweet spot


Use natural language for most of the specification Write as clearly and concisely as possible Use pictures, diagrams, and dialogs to further

illustrate the intent and features of the application

Augment with use cases and other formal techniques to fully define the functionality

Ambiguity vs. Understandability: What to Do?


ref - IEEE 1993

Ranked by importance

SR103SR172SR192SR71SR63

SR172SR103SR63 SR71 SR192

Ranked by stability

Qualities of an SRS: Ability for Ranking

A Requirements Specification is able to be “ranked” for importance and stability if Each requirement in it has an identifier to indicate the

importance and stability of that particular requirement


IEEE 1993

- The system supports up to 1,000 simultaneous users- The system shall respond to an arbitrary query in 500 msec.- The color shall be a pleasing shade of green- The system shall be user friendly- The system shall export view data in comma separated format

Qualities of an SRS: Verifiable A Requirements Specification is “verifiable” if:

Every requirement in it is verifiable. [… to a degree that convinces everybody!]

There exists some finite, cost-effective process with which a person or machine can check that the product meets the requirement

Are these requirements verifiable?If not, what is a better way to state them?

(Involve QA folks to help decide)


IEEE 1993

Qualities of an SRS: Modifiable

A Requirements Specification is “modifiable” if: Its structure and style are such that any changes to

requirements can be made easily, completely, and consistently, while retaining the structure and style.

Features to facilitate modifiability

• Well organized• Table of contents• Index• Cross references• Minimum redundancy


ref - IEEE 1993

Qualities of an SRS: Traceable A Requirements Specification is “traceable” if:

The origin of each requirement is clear and each requirement can be referenced in future development

• Backward traceability (to previous stages of definition or development)

• Forward traceability (to all documents spawned by the SRS)

Hints: Make sure every requirement is referenceable

• Use unique numbers • Use labels• Use “shall" or other unique identifiers• Use a requirements repository to maintain traceability


Qualities of an SRS: Understandable

A Requirements Specification is “understandable” if: Both the user and supplier communities are able to fully

comprehend the requirements stated in it Hints:

Early document should focus on general description and features of the system

Requirements writers must understand both audiences Use cases can help with understanding the system’s

functional requirements and boundaries


Adapted from Alan Davis

What Is Not in an SRS?

Design - How to accomplish the requirements Design Model specifies sub-components of a system

and/or their interfaces with other sub-components Verification - How you’ll know the requirements

have been met Test Model specifies test cases and test procedures

Project Data - When the requirements will be met Software Development Plan specifies schedules,

verification and validation plans, and configuration management plans


Review: Refine the System Definition

1. What is in a software requirement specification?

2. What are the properties of a use case?3. What is the purpose of the flow of events in a use case?

Who is it written for? What does the basic flow describe? What are some different types of alternative flows?

4. What are pre- and post-conditions? When should they be used?

5. What is the purpose of the “Special Requirements” of a use case?

(Continued )


Review: Refining the System Definition6. What are some types of non-functional requirements?

Where should they each be specified?

7. Is your industry bound by legal or regulatory requirements? If so, what types of specifications should be written to assure

compliance?

8. What is a design constraint? Where is it documented?9. What are some measures of a high quality software

requirement specification?10. What is not included in an SRS?