Requirements

Reference: Software Engineering, by Ian Sommerville, 6th edition, Chapters 5, 6, & 8

CMSC 345, Spring 2003 2

Objectives• To introduce and contrast user and system

requirements• To explain functional and non-functional

requirements• To present guidelines for writing system

requirements• To introduce the concept of use cases for

describing functional requirements

CMSC 345, Spring 2003 3

Requirements Engineering• The process of establishing

– the services that are required of the system, and

– the constraints under which it operates and is developed

• The requirements themselves are the descriptions of both of these items.

CMSC 345, Spring 2003 4

Who’s Who?• Client – the person(s) paying for the

development and will become the owner of the product

• Customer – the person who will buy the product off the shelf (mass marketing), or who has the final say as to whether the product is acceptable (in-house development). May be the same as the client

• Stakeholder – anyone who should have some direct or indirect influence on the system requirements

Reference: Mastering the Requirements Process, Robertson and Robertson

CMSC 345, Spring 2003 5

Types of Requirements• User requirements

– Should describe requirements so that they are understandable by those who do not have detailed technical knowledge. Written mainly for customers (end users)

• System requirements– A structured document setting out detailed descriptions of

the system services and constraints. Written as a contract between client and contractor

• Software design specification– An abstract description of the software design that can

serve as a basis for a more detailed design. Bridges the gap between requirements and design. Written for developers

CMSC 345, Spring 2003 6

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

CMSC 345, Spring 2003 7

Functional and Non-functional Requirements

• Functional requirements– Statements of services the system should provide,

how the system should react to particular inputs, and how the system should behave in particular situations

• Non-functional requirements– Constraints on the services or functions offered by the

system such as timing constraints, constraints on the development process, standards, etc.

CMSC 345, Spring 2003 8

Functional Requirements

• Describe functionality or system services• These services depend on

– the type of software being developed– the expected users of the software

• Functional user requirements may be high-level statements of what the system should do, but functional system requirements should describe the system services in detail.

CMSC 345, Spring 2003 9

Functional Requirement Examples

• The user shall be able to add or delete problems to/from the problem collection.

• The user shall be able to preview an examination on the monitor.

• A student shall be able to take an examination on-line.

• The system will automatically grade an examination upon completion by the student.

CMSC 345, Spring 2003 10

Requirements Imprecision• Problems arise when requirements are not

precisely stated.• Ambiguous requirements may be interpreted in

different ways by developers and clients.• Requirements should also be verifiable.• Examples:

– The user shall be able to modify the problem collection.

– The user shall be able to use an existing exam.

CMSC 345, Spring 2003 11

Requirements Completeness and Consistency

• In principle, requirements should be both complete and consistent.

• Complete– They should include descriptions of all required

functionality• Consistent

– There should be no conflicts or contradictions in the descriptions of the system functions

• In practice, it is impossible to produce a complete and consistent requirements document.

CMSC 345, Spring 2003 12

Non-functional Requirements• Define system properties and constraints• Examples:

– response time– storage requirements– process requirements (e.g., must use a particular

CASE system, programming language, or development method)

• Non-functional requirements may be more critical than functional requirements. If one is not met, the system may be useless.

CMSC 345, Spring 2003 13

Non-functional Requirements Examples

Product requirements- An examination shall accommodate true/false,

multiple choice, and short answer questions.- An exam question and the space for its answer

must not be divided between two printed pages.

- The system must run under Red Hat Linux, Version 6.2.

- The system must be written in C++, compilable using Microsoft Visual C++, Version 6.0.

CMSC 345, Spring 2003 14

More Non-functional Requirements

User interface requirements- The user interface shall be text-based.- The user interface shall be menu-driven.- The UMBC logo shall always be displayed

in the upper right-hand corner of the screen.

CMSC 345, Spring 2003 15

More Non-functional Requirements

Organizational requirements– The system development process and deliverable

documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95.

External requirements– The system shall not disclose any personal

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

CMSC 345, Spring 2003 16

NFRs Must Be Verifiable, Too!

• Non-verifiable– The system should be easy to use by experienced

controllers and should be organized in such a way that user errors are minimized.

• Verifiable– 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.

CMSC 345, Spring 2003 17

Some Requirements 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

CMSC 345, Spring 2003 18

Writing Requirements• Requirements may be written using a natural

language (common for user requirements)– Lack of clarity, possibly ambiguous– Requirements confusion

• Functional and non-functional requirements tend to be mixed-up

– Requirements amalgamation• Several different requirements may be expressed together

• Tables and diagrams may help

CMSC 345, Spring 2003 19

Example:Editor Grid Requirement

2.6 Grid 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.

CMSC 345, Spring 2003 20

Problems!• Difficult to read• Mixes three different requirements:

– Functional requirement (the need for a grid)– Non-functional requirement (grid units)– Non-functional UI requirement (grid

switching)

CMSC 345, Spring 2003 21

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 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.

CMSC 345, Spring 2003 22

Some Guidelines for Writing Requirements

• Invent or find a standard format and use it for all requirements.

• Use language in a consistent way. • Use “shall” or “will” for mandatory requirements, “should”

for desirable requirements.• Use text highlighting (e.g., italics) to identify key parts of

the requirement.• Do not use vague phrases (e.g., “around a month,”

“have basic knowledge of”)• Every requirement must be verifiable.• Every requirement should be numbered for traceability.

CMSC 345, Spring 2003 23

Use CasesA way of describing a system’s functional

requirements• Describes the system’s behavior under various conditions

as the system responds to a request from one of the stakeholders called the primary actor.

• The primary actor initiates some interaction with the system to accomplish some goal.

• The system responds, protecting the interests of all of the stakeholders.

• Different sequences of behaviors (scenarios) can unfold, depending on the request and the conditions surrounding the request. The use case gathers these scenarios together.