Slide 1

CS 310 Ch 6: Software Requirements

Requirements engineering: establishing the services that

the customer requires from a system and the constraints

under which it operates and is developed

Requirements: descriptions of the system services and

constraints that are generated during requirements

engineering

Slide 2

Hypothetical Problem: set up a Software Assistance Center

What are the requirements?• are we thinking the whole system or just the programming

Is there any organization to this?

How would you present this to Dean Miller-Bernal?

How would you present this to someone who will build it?

Slide 3

What is a requirement?

What the system should do, not how• what: maintain student grades

• how: store student grades in a MySQL database with web front-end

Range: • a high-level abstract statement of a service or of a system constraint

• a detailed mathematical function (how grades are calculated)

Inevitable since requirements may• be the basis for a bid - therefore open to interpretation

• be the basis for the contract - therefore detailed

Both may be called requirements

Our goal: make them as specific as possible

Slide 4

Levels of requirement

User requirements• statements in natural language plus diagrams of the services the system

provides and its operational constraints–written for system users who don’t have detailed technical knowledge

• problems» lack of clarity: precision can make the document difficult to read» requirements confusion: functional and non-functional mixed-up» amalgamation: several different requirements lumped together

System requirements (more detailed than user requirements)• a structured document setting out detailed descriptions of the system services

• may be used as part of the system contract

• serves as a basis for building the system and for acceptance testing

Don't separate these in your project, aim for a complete, detailed document

Slide 5

User versus system requirement

Comment: I don’t make this distinction. A spec should contain the details.

System requirements specification1.1 The system will store grades for each student enrolled in CS 10x1.2 These grades will be retained for 5 years1.3 TAs must logon to enter or change student grades1.4 TAs may change grades only in courses to which they have been granted permission1.4 The system will log each change to a grade1.5 A student must logon and can see only grades in courses she is taking1.6 The system will log each failed login attempt

User requirement definition1 The system will allow TAs to enter grades for each student in CS 10x2 The system will allow students to check their current grade

Slide 6

6.1 Functional and non-functional requirements

Functional• services the system should provide, how the system should react to

particular inputs and how the system should behave in particular situations

• the system will allow TAs to enter grades for each student in CS 10x

Non-functional• constraints on the system services such as timing constraints,

constraints on the development process, standards, etc.• the system will be available 24/7

Domain • requirements that come from the application domain of the system and

reflect characteristics of that domain• e.g. the laws of physics• e.g. how grades are calculated

Slide 7

Non-functional requirements

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements

*

* How the product must behave

Slide 8

Examples

Product requirement• all communication between the system and the user shall be

transferred in XML

Organizational requirement• the system development process and deliverable documents shall

conform to the process and deliverables defined in XYZCo-SP-STAN-05

External requirement• the system shall not disclose any personal information about

customers apart from their name and reference number to the operators of the system

Slide 9

Requirements measures

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

Slide 10

Back to the Software Assistance Center

How about these?• it will be staffed by smart people

• they will answer questions

• it will be open a lot

• the room will be nice

Do: email me 5-10 representative functional and non functional

requirements

Slide 11

So, how do we write specifications?

Natural language• ambiguous

• over-flexible (one can say the same thing may be said several ways)

• lack of modularization

Alternatives -various more formal notations• structured natural language (my favorite)

• using a standard form

• using a program design language (PDL)

Slide 12

Structured NL specification

3.5.1 Adding nodes to a design3.5.1.1 The editor shall provide a facility for users to add nodes of a specified

type to their design.

3.5.1.2 The sequence of actions to add a node should be as follows:

1. The user should select the type of node to be added.

2. The user should move the cursor to the approximate node position in thediagram and indicate that the node symbol should be added at thatpoint.

3. The user should then drag the node symbol to its final position.

Rationale: The user is the best person to decide where to position a node onthe diagram. This approach gives the user direct control over nodetype selection and positioning.

Specification: ECLIPSE/WS/Tools/DE/FS. Section 3.5.1

Slide 13

Form-based node specification

Insulin Pump/Control Software/SRS/3.3.2

Function Compute insulin dose: Safe sugar level

Description Computes the dose of insulin to be delivered when the current measured sugar level is inthe safe zone between 3 and 7 units.

Inputs Current sugar reading (r2), the previous two readings (r0 and r1)

Source Current sugar reading from sensor. Other readings from memory.

Outputs CompDose Š the dose in insulin to be delivered

Destination Main control loop

Action: CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate ofincrease is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose iscomputed by dividing the difference between the current sugar level and the previous level by 4 androunding the result. If the result, is rounded to zero then CompDose is set to the minimum dose that canbe delivered.

Requires Two previous readings so that the rate of change of sugar level can be computed.

Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin..

Post-condition r0 is replaced by r1 then r1 is replaced by r2

Side-effects None

Slide 14

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

Slide 15

PDL 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

Slide 16

6.5 Software requirements document

The official statement of what the developers must build

Not a design document. As far as possible, it describes what the system should do, not howwhat: maintain author, title, and price in a database

how: store author, title, and price at locations x-y

It should be• easy to read/change

• the basis for system design

• the basis for system testing

• a reference tool for maintenance (NO)

• forethought about the system life cycle (NO, only as requirements)

Users of a requirements document

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

engineersno

Slide 18

Guidelines for writing requirements

Use a standard format for all requirements

Use language consistently. Use “shall” for mandatory requirements, “should” for desirable requirements

(I don't believe "desirable" requirements belong)

Avoid computer jargon

Be concise• remove extra words

• do not cover a requirement more than once

Avoid ambiguity

Slide 19

Exercise

Rewrite the following requirements so that they may be

objectively validated. You may make any reasonable

assumptions about them.

The software system shall provide acceptable performance under maximum load conditions

The system interface shall use a character set as available on the standard terminal

If the system fails in operation, there should be a minimal loss of data

The software development process used shall ensure that all of the required reviews have been carried out

The software will be well-written

The software must be developed in such a way that it can be used by inexperienced users

Slide 20

Requirements document structure

Introduction: describe need for the system and how it fits with business objectives

System models: define models showing system components and relationships

Functional requirements: the services to be provided

Non-functional requirements: constraints on the system and the development process

Appendices. e.g.

• glossary: define technical terms used• system hardware platform• database requirements (as an ER model perhaps)

This differs somewhat from the text