1

Text Layout Introduction (1-4) Team Skill 1 – Analyzing the problem (5-7) Team Skill 2 – Understanding User and Stakeholder

Needs (8-13) Team Skill 3 – Defining the System (14-17) Team Skill 4 – Managing Scope (18-19) Team Skill 5 – Refining the System Definition ( 20-24) Team Skill 6 – Building the Right System (25-31)

2

Software Requirements – A More Rigorous Look

Chapter 20

3

Five Major Classes of Things Inputs to the system

Contents of the inputs Details of input devices

Outputs from the system Description of output devices Protocol and formats of information generated by the system

Functions of the system Mapping inputs to outputs and combinations

Attributes of the system Typical non-behavioral requirements (ilities)

Attributes of the system environment Ability to operate with other systems

4

Looking Deeper into Software Requirements Relationship between requirements and use cases

Use cases are just one way to express software requirements Relationship between features and requirements

Direct relationship and requirements are more specific than features

What versus How Requirements tell us what the system must do Requirements should not tell how or contain any unnecessary

design Exclude project information

Project information (schedule, CM plans, budgets, etc. ) are managed differently and should not be part of the requirements

5

Iterating Requirements and Design Requirements discovery, definition, and design decision

are circular

Current requirements cause us to consider selecting certain design options,

Selected design options may initiate new requirements

and

6

Three Types of Requirements Functional

Express how the system behaves Inputs, outputs, and functions it provides to its users Captured in use cases

Nonfunctional Attributes of the system or system environment “ilities”

Design constraints Impose limits on the design of the system Definition: restrictions on the design of a system, or the process

by which a system is developed, that do not affect that external behavior of the system but that must be fulfilled to meet technical, business, or contractual obligations

7

Key Points A complete set of requirements can be determined by

defining the inputs, outputs, functions, and attributes of the system plus the attributes of the system environment

Requirements should exclude project-related information, such as schedules, project plans, budgets, and tests, as well as design information

The requirements/design process is iterative; requirements lead to the selection of certain design options, which in turn may initiate new requirements

Design constraints are restrictions on the design of the system or on the process by which a system is developed

8

Refining the Use CasesChapter 21

9

Anatomy of a Use Case Review actors

Identify not only the initiating actors but those impacted as well Review the name

No two use cases can have the same name The use case should begin with an action verb

Refine description Make any adjustment based on the actors or name updates

Refine flow of events Look for other alternate paths and error conditions

Identify pre- and post-conditions These conditions should be one that the users can observe

10

Extending Use Cases Used to add functionality for a later release Simplifies maintenance of the use case and allows the

team to focus on the extension Extension points can be provided in the base use case

to map functionality The extended use case can represent optional behavior

Control Light

Update Display Indicator

«extends»If some of the HOLIS systems included an optional “light bar” indicator on the Control Switch, then an extended use case could extend the behavior of the base Control Light use case

11

Including Use Cases Used with patterns of user and system behavior reoccur

in a variety of places Reduces maintenance, when a change occurs, it only

needs to be documented in the included use case and not all the places the

Common behavior takes place

12

Key Points To support development and testing activities, the use

cases defined earlier in the project must be more fully elaborated

The use-case model is reviewed and will often be refactored as well

A well-elaborated use case also defines all alternative flows, pre- and post-conditions, and special requirements

The additional use-case relationships extend and include help the team structure and maintain the use-case model

13

Developing the Supplementary SpecificationChapter 22

14

Nonfunctional Requirements Usability – ease of use

Specify the required training time for a use to become minimally productive

Specify measurable task time for typical tasks or transactions Time to place a typical order

Compare usability to another commonly known system “The system shall be judged by 90% of the users to be at least as

usable as the existing XYZ system” Specify required features of online help systems, tool tips,

context-sensitive help, etc. Follow conventions and standards that have been developed for

human-to-machine interface IBM’s Common User Access (CUA) standards

15

Nonfunctional Requirements Reliability

Availability – System must be available X.XXX% between hours of 7am and midnight.

Mean time between failures (MTFB) – usually specified in hours Mean time to repair (MTTR) – how long system can be out of

operation after a failure Accuracy – what precision is required in numerical outputs Maximum bugs, or defect rate – bugs/KLOC Bugs per type – usually categorized in terms of minor,

significant, and critical

16

Nonfunctional Requirements Performance

Response time for a transaction Throughput: transactions per second Capacity: number of customers or transactions the system can

handle Degradation modes: the acceptable mode of operations when

the system has been degraded Memory, storage and bandwidth

17

Nonfunctional Requirements Supportability

Ability of the software to be easily modified to accommodate enhancements and repairs

Could stipulate response time of the maintenance group from simple enhancements, moderate enhancements, and complex enhancements

Where a system is known to have future modifications…how fast these modification can be made

This could get into design constraints and start to require a DBMS or programming styles and standards like run-time binding

18

Design Constraints Three sources

Restriction of design options Conditions imposed on the development process Regulations and imposed standards

Handling design constraints Distinguish them from other requirements, use a tag Include all design constraints in a special section of the

requirements document Identify the source of each design constraint Document the rationale of each design constraint

19

Linking the Supplementary Specification to the Use Cases

Define certain classes of nonfunctional requirements, then link each class to a use case

For example: classes of response time may be Class 1: 0 to 250 millisecs Class 2: 251 to 499 milisecs Class 3: 0.5 to 2 secs Class 4: 2.1 to 12 secs Class 5: 12.1 secs to 60 mins

Use Case A might record Class 2 for main flow events and Class 4 for all exceptions

While Use Case B might record Class 5

20

Supplementary Specification Template Page 268 of text

21

On Ambiguity and SpecificityChapter 23

22

Light Box Exercise

On Off

Power

Count

Even Odd

Features• Microprocessor

Controlled• Keeps track of whether

count button has been pressed an even or odd number of times

• Burned-out-bulb detector flashes remaining bulb

Requirements• After On pushed but before Off pushed, system is termed

“powered on”• After Off pushed but before On pushed, system is termed

“powered off”, and no lights shall be lit• Since most recent On press, if Count has been pressed an

odd number of times, Odd shall be lit• Since most recent On press, if Count has been pressed an

even number of times, Even shall be lit• If either light burns out, the other light shall flash every 1 sec

23

Light Box Exercise

Off

Off

On

On

0 1 2 3 4 5 6

Duty Cycle A

Duty Cycle B

Which duty cycle does the requirement want?

24

Key Points

The requirements “sweet spot” is the balance point of the greatest amount of understandability and the least amount of ambiguity

A learned skill, finding the sweet spot will depend on the team members’ abilities, the application context, and the level of certainty you must provide so that your system works as intended

If the risk of misunderstanding is unacceptable, more formal requirements techniques may need to be applied

Always include a glossary

25

Technical Methods for Specifying Requirements

Chapter 24

26

Pseudocode A “quasi” programming language A combination of the informality of natural language with

the strict syntax and control structure of a programming language

Should be possible for a nonprogramming person to understand

The algorithm for calculating deferred-service revenue earned for any month is:

Set SUM(X)=0FOR each customer X

IF customer purchased paid supportAND ((Current month) >= (2 months after ship date))AND ((Current month) <= (14 months after ship date))

THEN Sum(X)=Sum(X) + (amount customer paid)/12END

27

Finite State Machines State transition diagram

Even lit

Odd lit Odd lit/LOUT

Even lit/LOUT

Off

Light burned out

Light burned out

Count Count 1 sec 1 sec

off

offoff

off

on

28

Finite State Machines

State On Press

Off Press

Count Press

Bulb Burns Out

Every Second

Output

Off Even lit

LO/Odd lit

LO/Even lit

Both off

Even lit Off Odd lit LO/Even lit

Even lit

Odd lit Off Even lit LO/Odd lit Odd lit

Light outEven lit

Off Off Even lit

Light outOdd lit

Off Off Odd lit

29

Decision Tree for HOLIS Emergency Sequence

Has emergency sequence occurred?

Is remote notification enabled?

Initiate emergency message

Did remote security respond?

Do nothing

Activate siren

Activate siren

Do nothing

Is local alarm

enabled?

Do nothing

Yes

Yes

Yes

Yes

No

No

No

No

30

Activity Diagrams

Get req ref from doc

Get text ref from doc

Remove req from DB

Remove req from Doc

[no more]

[more]

[empty][not empty]

Activity diagrams are a nuisance to keep up-to-date

31

Entity-Relationship Model Description of the structure and relationships among

data within the system Provides a high-level architectural view of the data Must take time to learn the notation – a disadvantage Example on page 285

32

Key Points

Technical methods for specifying requirements are appropriate when the requirement description is too complex for natural language or if you cannot afford to have the specification misunderstood

Technical methods include pseudocode, finite state machines, decision trees, activity diagrams, entity-relationship models, and many others