11

To introduce the concepts of user To introduce the concepts of user and system requirementsand system requirements

To describe functional and non-To describe functional and non-functional requirementsfunctional requirements

To explain how software To explain how software requirements may be organised in a requirements may be organised in a requirements documentrequirements document

ObjectivesObjectives

22

Requirements EngineeringRequirements Engineering

The process of establishing the services The process of establishing the services that a customer requires from a system that a customer requires from a system and the constraints under which it can and the constraints under which it can operate and should be is developed. operate and should be is developed. Sommervil Sommervil 0404

The requirements themselves are the The requirements themselves are the descriptions of the system services and descriptions of the system services and constraints that are generated during the constraints that are generated during the requirements engineering process.requirements engineering process.

33

What is a requirement?What is a requirement?

Requirements are the set of things that a Requirements are the set of things that a customer requires with a number of constraints customer requires with a number of constraints that must be satisfied on the final system.that must be satisfied on the final system.

It can be represented in high-level abstract It can be represented in high-level abstract statement of a service a detailed mathematical statement of a service a detailed mathematical functional specification.functional specification.

Requirements may serve as:Requirements may serve as:• The basis for a bid for a contract - therefore must be open to The basis for a bid for a contract - therefore must be open to

interpretation;interpretation;• The basis for the contract itself - therefore must be defined in The basis for the contract itself - therefore must be defined in

detail;detail;

44

Examples of RequirementsExamples of Requirements

““Fire Alarm must go off when a movement Fire Alarm must go off when a movement is detected before 06:00 and after 19:00”is detected before 06:00 and after 19:00”

““The system must dial 999 to inform the The system must dial 999 to inform the Police”Police”

““Customers should be able to view their Customers should be able to view their remaining balance”remaining balance”

““The system should identify employee by The system should identify employee by face”face”

55

Requirements EngineeringRequirements Engineering

Can be described in:Can be described in: ElicitationElicitation Analysis and negotiationAnalysis and negotiation Specs generationSpecs generation System modelingSystem modeling ValidationValidation ManagementManagement

66

Why Reqs are non-tech?Why Reqs are non-tech?

User cannot understand technical detailsUser cannot understand technical details Maybe they could after system Launched!Maybe they could after system Launched!

Reduce restrictions on code developersReduce restrictions on code developers Satisfy requirements using whatever possible Satisfy requirements using whatever possible

techniques and tools.techniques and tools.

Customer may specify details that might Customer may specify details that might confuse more than clarify! confuse more than clarify!

Fast system, large size, easy to use … etcFast system, large size, easy to use … etc

Requirement might change over timeRequirement might change over time

77

Characteristics of good Spec.Characteristics of good Spec. Implementation FreeImplementation Free

• Omit technical details.Omit technical details. CompleteComplete

• Should include descriptions of all facilities required.Should include descriptions of all facilities required. ConsistentConsistent

• There should be no conflicts or contradictions in the There should be no conflicts or contradictions in the descriptions of the system facilities.descriptions of the system facilities.

UnambiguousUnambiguous• Common vocabularies are used.Common vocabularies are used.• Ambiguous requirements may be interpreted in different ways Ambiguous requirements may be interpreted in different ways

by developers and usersby developers and users Concise and MinimalConcise and Minimal

• No duplication or un-necessary contents.No duplication or un-necessary contents. Clear and UnderstandableClear and Understandable TestableTestable

• Example: “Experienced controllers shall be able to use all the Example: “Experienced controllers shall be able to use all the system functions after a total of two hours training. After this system functions after a total of two hours training. After this training, the average number of errors made by experienced training, the average number of errors made by experienced users shall not exceed two per day”.users shall not exceed two per day”.

88

Exercise Exercise

Are The following statements right or wrong Are The following statements right or wrong Specs?Specs?

““Write a Java program to provide a personal telephone directory. It should implement functions to look up a number and to enter a new telephone number. The program should provide a friendly user interface.”

“ Data should be stored in Magnetic Disk and the system must retrieve data in 1ms”

99

Types of requirementTypes of requirement User requirementsUser requirements

• Statements in natural language plus diagrams of the Statements in natural language plus diagrams of the services the system provides and its operational services the system provides and its operational constraints. Written for customers.constraints. Written for customers.

System requirementsSystem requirements• A structured document setting out detailed A structured document setting out detailed

descriptions of the system’s functions, services and descriptions of the system’s functions, services and operational constraints. Defines what should be operational constraints. Defines what should be implemented so may be part of a contract between implemented so may be part of a contract between client and contractor.client and contractor.

1010

Functional and non-functional Functional and non-functional requirementsrequirements

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

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

Non-functional requirementsNon-functional requirements• constraints on the services or functions offered by the constraints on the services or functions offered by the

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

Domain requirementsDomain requirements• Requirements that come from the application domain Requirements that come from the application domain

of the system and that reflect characteristics of that of the system and that reflect characteristics of that domain.domain.

1111

Functional requirementsFunctional requirements

Describe functionality or system services.Describe functionality or system services. Depend on the type of software, expected Depend on the type of software, expected

users and the type of system or users and the type of system or environment where the software is used.environment where the software is used.

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

1212

Non-functional requirementsNon-functional requirements

Define system properties and constraints e.g. Define system properties and constraints e.g. reliability, response time and storage reliability, response time and storage requirements. Constraints are I/O device requirements. Constraints are I/O device capability, system representations, etc.capability, system representations, etc.

Process requirements may also be specified Process requirements may also be specified authorizing a particular CASE system, authorizing a particular CASE system, programming language or development programming language or development method.method.

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

1313

Example of Non-Functional ReqsExample of Non-Functional Reqs

The user interface for LIBSYS shall be The user interface for LIBSYS shall be implemented as simple HTML without implemented as simple HTML without frames or Java applets.frames or Java applets.

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

The system shall not disclose any personal The system shall not disclose any personal information about customers apart from information about customers apart from their name and reference number to the their name and reference number to the operators of the system.operators of the system.

1414

Elicit RequirementsElicit Requirements

The activity of eliciting requirements involves the engineer and users talking together, with the former trying to understand the latter by asking questions and writing notes.

1515

Elicitation TechniquesElicitation Techniques

Background readingBackground reading Documents inspectionDocuments inspection InterviewsInterviews QuestionnairesQuestionnaires BrainstormingBrainstorming EthnographyEthnography PrototypingPrototyping Use-cases and scenariosUse-cases and scenarios

1616

What to Elicit?What to Elicit?

Description of problem domain.Description of problem domain. medical, chemistry, math … etc.medical, chemistry, math … etc.

List of Problems.List of Problems. Any client-imposed constraints upon Any client-imposed constraints upon

behavior or structure of the system.behavior or structure of the system. The main motivation behind the The main motivation behind the

development.development.

1717

Sources of InformationSources of Information

ClientClient Documentation of Pre-exiting systemDocumentation of Pre-exiting system Users of pre-existing systemUsers of pre-existing system Possible users of the new systemPossible users of the new system Competitor’s productCompetitor’s product Domain Expert Domain Expert Relevant standardsRelevant standards

1818

Guidelines for writing Guidelines for writing requirementsrequirements

Invent a standard format and use it for Invent a standard format and use it for all requirements.all requirements.

Use language in a consistent way. Use Use language in a consistent way. Use shall for mandatory requirements, shall for mandatory requirements, should for desirable requirements.should for desirable requirements.

Use text highlighting to identify key Use text highlighting to identify key parts of the requirement.parts of the requirement.

Avoid the use of computer terminology.Avoid the use of computer terminology.

1919

Problems with natural languageProblems with natural language Lack of clarity Lack of clarity

• Precision is difficult without making Precision is difficult without making the document difficult to read.the document difficult to read.

Requirements confusionRequirements confusion• Functional and non-functional Functional and non-functional

requirements tend to be mixed-up.requirements tend to be mixed-up. Requirements amalgamationRequirements amalgamation

• Several different requirements may Several different requirements may be expressed together.be expressed together.

2020

Sequence diagramsSequence diagrams These show the sequence of events that These show the sequence of events that

take place during some user interaction take place during some user interaction with a system.with a system.

You read them from top to bottom to You read them from top to bottom to see the order of the actions that take see the order of the actions that take place.place.

Cash withdrawal from an ATMCash withdrawal from an ATM• Validate card;Validate card;• Handle request;Handle request;• Complete transaction.Complete transaction.

2121

Sequence diagram of ATM Sequence diagram of ATM withdrawalwithdrawal

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

2222

System Behavior ModelingSystem Behavior Modeling

Data Flow Diagram (DFD)Data Flow Diagram (DFD) Graphical representation of the flow of data Graphical representation of the flow of data

throughout a system.throughout a system. (see e.g. P175)(see e.g. P175)

2323

System Behavior ModelingSystem Behavior Modeling

State Transition Diagram (STD)State Transition Diagram (STD) Describes the possible states of an object as events Describes the possible states of an object as events

occuroccur

2424

Key pointsKey points

Requirements set out what the system should Requirements set out what the system should do and define constraints on its operation and do and define constraints on its operation and implementation.implementation.

Functional requirements set out services the Functional requirements set out services the system should provide.system should provide.

Non-functional requirements constrain the Non-functional requirements constrain the system being developed or the development system being developed or the development process.process.

User requirements are high-level statements of User requirements are high-level statements of what the system should do. User requirements what the system should do. User requirements should be written using natural language, should be written using natural language, tables and diagrams.tables and diagrams.