fahim.khan@iiu.edu.pk

Software Engineering

Lecture No:13, 14, 15

Lecture # 7Requirements engineering

Fahim KhanAssistant Professor of Computer Science

UOL, Sargodha

Requirements Engineering

• The broad spectrum of tasks and techniques that lead to an understanding of requirements is called

requirements engineering.

• Requirements engineering provides the appropriate mechanism for understanding what the

customer wants, analyzing needs, assessing feasibility, negotiating a reasonable solution,

specifying the solution unambiguously, validating the specification, and managing the

requirements as they are transformed into an operational system.

• The process of establishing the services that the customer requires from a system and the

constraints under which it operates and is developed.

• The requirements themselves are the descriptions of the system services and constraints that are

generated during the requirements engineering process.

Requirements Engineering

• Requirements Engineering (RE) is a set of activities concerned with identifying and communicating the purpose of a software-intensive system, and the contexts in which it will be used. Hence, RE acts as the bridge between the real world needs of users, customers, and other constituencies affected by a software system, and the capabilities and opportunities afforded by software-intensive technologies.

What is a requirement?

• It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.

• This is inevitable as requirements may serve a dual function• The process of establishing the services that the customer requires

from a system and the constraints under which it operates and is developed.

– May be the basis for a bid for a contract - therefore must be open to interpretation;– May be the basis for the contract itself - therefore must be defined in detail;– Both these statements may be called requirements.

• RE Allows the requirements engineer to examine–the context of the software work to be performed–the specific needs that design and construction must

address–the priorities that guide the order in which work is to be

completed–the information, function, and behavior that will have a

profound impact on the resultant design

Importance of RE

“The hardest single part of building a software system is deciding what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.” -- Frederick P. Brooks

“Delivery is not necessarily the best time to discover the user requirements.” (Urban Wisdom)

Importance of RE“Done well, requirements engineering presents an opportunity to reduce costs and increase the quality of software systems. Done poorly, it could lead to a software project failure.” –

Software Engineering Institute (SEI)

11/7/2010 7

By Proper Requirements Engineering We Can…

• … know what the system is supposed to do• … keep track of the current status of requirements• … determine the impact of a requirements change

Requirements Engineering Tasks• Seven distinct tasks

– Inception– Elicitation– Elaboration– Negotiation– Specification– Validation– Requirements Management

• Some of these tasks may occur in parallel and all are adapted to the needs of the project

• All strive to define what the customer wants?

• All serve to establish a solid foundation for the design and construction of the software

Example Project: Campus Information Access Kiosk

• Both podium-high and desk-high terminals located throughout the campus in all classroom buildings, admin buildings, labs, and dormitories

• Hand/Palm-login and logout (seamlessly)• Voice input• Optional audio/visual or just visual output• Immediate access to all campus information plus

– E-mail – Cell phone voice messaging

RequirementsManagement

Validation

Inception

Elicitation

Elaboration

Negotiation

Specification

Inception Task

• During inception, the requirements engineer asks a set of questions to establish…– A basic understanding of the problem– The people who want a solution– The nature of the solution that is desired– The effectiveness of preliminary communication and collaboration between the

customer and the developer

• Through these questions, the requirements engineer needs to… – Identify the stakeholders– Recognize multiple viewpoints– Work toward collaboration– Break the ice and initiate the communication

The First Set of Questions

• Who is behind the request for this work?• Who will use the solution?• What will be the economic benefit of a successful

solution?• Is there another source for the solution that you need?

These questions focus on the customer, other stakeholders, the overall goals, and the benefits

The Next Set of Questions

• How would you characterize "good" output that would be generated by a successful solution?

• What problem(s) will this solution address?• Can you show me (or describe) the business environment in

which the solution will be used?• Will special performance issues or constraints affect the

way the solution is approached?

These questions enable the requirements engineer to gain a better understanding of the problem and allow the customer to voice his or her perceptions about a solution

The Final Set of Questions

• Are you the right person to answer these questions? Are your answers "official"?

• Are my questions relevant to the problem that you have?• Am I asking too many questions?• Can anyone else provide additional information?• Should I be asking you anything else?

These questions focus on the effectiveness of the communication activity itself

Feasibility studies• A feasibility study decides whether or not the proposed

system is worthwhile.• A short focused study that checks

– If the system contributes to organisational objectives;– If the system can be engineered using current technology and

within budget;– If the system can be integrated with other systems that are used.

11/7/2010 16

Feasibility study implementation• Based on information assessment (what is required), information

collection and report writing.• Questions for carrying out the feasibility

– What if the system wasn’t implemented?– What are current process problems?– How will the proposed system help business and requirements?– What will be the integration problems?– Is new technology needed? What skills?– What must be supported by the proposed system and what not?

11/7/2010 17

Context-Free Questions• help us gain an understanding of the real problem without

biasing the user's input.• questions about the nature of the user's problem without

context for a potential solution. • Can be asked regardless of the nature of the project.• These questions force us to listen before attempting to invent

or describe a potential solution.

11/7/2010 18

Context-Free Questions• Listening gives us a better understanding of the customer's

problem and any problems behind the problem. • E.g.

– What problems does this product solve? – What problems could this product create? – What environment is this product likely to encounter?

11/7/2010 19

Requirements Elicitation and Analysis• The process of identifying the needs and constraints of the

various stakeholders for a software system• Requirements elicitation is a process in which requirements

are gathered for the new system to be developed

11/7/2010 20

Elicitation Techniques• Interviews • Questionnaires• Requirements workshops• Storyboards• Ethno-methodology• Scenarios• Use-cases

11/7/2010 21

INTERVIEWING

• simple and direct technique that can be used in most circumstances.

• Convergence on some common needs will initiate a "requirements repository" for use during the project.

• Types:– Closed : pre-set agenda– Open-ended: no pre-set agenda– Normally a mix of closed and open-ended interviewing.

11/7/2010 22

Interviews in practice• Interviews are good for getting an overall understanding of what

stakeholders do and how they might interact with the system.• Interviews are not good for understanding domain requirements

– Requirements engineers cannot understand specific domain terminology;– Some domain knowledge is so familiar that people find it hard to articulate or

think that it isn’t worth articulating.

11/7/2010 23

Interviews• Make sure that the biases and predispositions of the

interviewer do not interfere with a free exchange of information.

• We must not let our context (background) interfere with understanding the real problem to be solved

11/7/2010 24

Questionnaires• There is no substitute for an interview.• Although the questionnaire technique is often used and appears

scientific because of the opportunity for statistical analysis of the quantitative results, the technique is not a substitute for interviewing.

• When it comes to requirements gathering, the questionnaire technique has some fundamental problems.– E.g. Relevant questions cannot be decided in advance.

11/7/2010 25

Questionnaires• It is difficult to explore new domains ("What you really should

be asking about is . . ."), and there is no interaction to explore domains that need to be explored.

• It is difficult to follow up on unclear user responses.• Indeed, some have concluded that the questionnaire

technique suppresses almost everything good about requirements gathering.

11/7/2010 26

Questionnaires• However, the questionnaire technique can be applied with good effect

as a corroborating technique after the initial interviewing and analysis activity.

• For example, if the application has a large number of existing or potential users and if the goal is to provide statistical input about user or customer preferences among a limited set of choices, a questionnaire can be used effectively to gather a significant amount of focused data in a short period of time.

• In short, the questionnaire technique, like all elicitation techniques, is suited to a subset of the requirements challenges that an organization may face.

11/7/2010 27

Requirements Workshops• The requirements workshop may be the most powerful technique

for eliciting requirements.• If we were to be given only one requirements elicitation technique

—one that we had to apply in every circumstance, no matter the project context, no matter what the time frame—we would pick the requirements workshop.

• The requirements workshop is designed to encourage consensus on the requirements of the application and to gain rapid agreement on a course of action, all in a very short time.

11/7/2010 28

Requirements Workshops• It gathers all key stakeholders together for a short but

intensely focused period (1-2 days)• The use of an outside facilitator experienced in requirements

elicitation can help ensure the success of the workshop.• Brainstorming is the most important part of the workshop.

11/7/2010 29

Requirements Workshops• It can expose and resolve political issues that are interfering

with project success.• The output, a preliminary system definition at the features

level, is available immediately.• The workshop is facilitated by a team member or, better yet,

by an experienced outside facilitator and focuses on the creation or review of the high-level features to be delivered by the new application.

11/7/2010 30

Sample Agenda for Requirements WorkshopTime Agenda Item Description

8:00–8:30 Introduction Review agenda, facilities, and rules

8:30–10:00 Context Present project status, market needs, results of user interviews, and so on

10:00–12:00 Brainstorming Brainstorm features of the application

12:00–1:00 Lunch Work through lunch to avoid loss of momentum

1:00–2:00 Brainstorming Continue brainstorming2:00–3:00 Feature definition Write out two- or three-sentence definitions for features

3:00–4:00 Idea reduction and prioritization

Prioritize features

4:00–5:00 Wrap-up Summarize and assign action items11/7/2010 31

Elaboration Task• During elaboration, the software engineer takes the information

obtained during inception and elicitation and begins to expand and refine it

• Elaboration focuses on developing a refined technical model of software functions, features, and constraints

• It is an analysis modeling task– Use cases are developed– Domain classes are identified along with their attributes and relationships– State machine diagrams are used to capture the life on an object

• The end result is an analysis model that defines the functional, informational, and behavioral domains of the problem

Developing Use Cases

• Step One – Define the set of actors that will be involved in the story– Actors are people, devices, or other systems that use the system or

product within the context of the function and behavior that is to be described

– Actors are anything that communicate with the system or product and that are external to the system itself

• Step Two – Develop use cases, where each one answers a set of questions

(More on next slide)

Use cases• Use-cases are a scenario based technique in Unified Modeling

Language (UML) which identify the actors in an interaction and which describe the interaction itself.

• A set of use cases should describe all possible interactions with the system.

• Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.

11/7/2010 34

Article printing use-case (Top Level)

Article printing

stick figure: ActorEllipse: a distinct class/category of interaction

11/7/2010 35

Complete LIBSYS system: all use cases

Article printing

Article search

User administration

Supplier Catalogue services

LibraryUser

LibraryStaff

11/7/2010 36

sequence diagram: Print article

User

item:Article

copyrightForm:Form

request

complete

myWorkspace:Workspace

myPrinter:Printer

request

return

copyright OK

deliver

article OK

print send

confirminform

delete

11/7/2010 37

Barriers to Elicitation• The "User and the Developer" Syndrome

– arises from the communication gap between the user and the developer.

– Users and developers are typically from different worlds, may even speak different languages, and have different backgrounds, motivations, and objectives

– Ease of omitting “obvious” information by users

11/7/2010 38

Elements of the Analysis Model

• Scenario-based elements– Describe the system from the user's point of view using scenarios that are depicted in use

cases and activity diagrams

• Class-based elements– Identify the domain classes for the objects manipulated by the actors, the attributes of

these classes, and how they interact with one another; they utilize class diagrams to do this

• Behavioral elements– Use state diagrams to represent the state of the system, the events that cause the system to

change state, and the actions that are taken as a result of a particular event; can also be applied to each class in the system

• Flow-oriented elements– Use data flow diagrams to show the input data that comes into a system, what functions

are applied to that data to do transformations, and what resulting output data are produced

Barriers to Elicitation• Users have incomplete understanding of their needs• Users have poor understanding of computer capabilities and

limitations• Analysts have poor knowledge of problem domain

11/7/2010 40

Negotiation Task• During negotiation, the software engineer reconciles the conflicts

between what the customer wants and what can be achieved given limited business resources

• Requirements are ranked (i.e., prioritized) by the customers, users, and other stakeholders

• Risks associated with each requirement are identified and analyzed

• Rough guesses of development effort are made and used to assess the impact of each requirement on project cost and delivery time

• Using an iterative approach, requirements are eliminated, combined and/or modified so that each party achieves some measure of satisfaction

The Art of Negotiation

• Recognize that it is not competition• Map out a strategy• Listen actively• Focus on the other party’s interests• Don’t let it get personal• Be creative• Be ready to commit

Specification Task

• A specification is the final work product produced by the requirements engineer

• It is normally in the form of a software requirements specification• It serves as the foundation for subsequent software engineering

activities• It describes the function and performance of a computer-based

system and the constraints that will govern its development• It formalizes the informational, functional, and behavioral

requirements of the proposed software in both a graphical and textual format

Typical Contents of a Software Requirements Specification

• Requirements– Required states and modes– Software requirements grouped by capabilities (i.e., functions, objects)– Software external interface requirements– Software internal interface requirements– Software internal data requirements– Other software requirements (safety, security, privacy, environment, hardware,

software, communications, quality, personnel, training, logistics, etc.)– Design and implementation constraints

• Qualification provisions to ensure each requirement has been met– Demonstration, test, analysis, inspection, etc.

• Requirements traceability– Trace back to the system or subsystem where each requirement applies

Characteristics of INDIVIDUAL Requirement Statements

• Complete• Correct• Feasible• Necessary• Prioritized• Unambiguous• Verifiable

11/7/2010 45

Complete• Each requirement must fully describe the functionality to be

delivered. • It must contain all the information necessary for the developer to

design and implement that bit of functionality. • If you know you're lacking certain information, use TBD (to be

determined) as a standard flag to highlight these gaps. Resolve all TBDs in each portion of the requirements before you proceed with construction of that portion.

11/7/2010 46

Correct

• Each requirement must accurately describe the functionality to be delivered.

• The reference for correctness is the source of the requirement, such as an actual customer or a higher level system requirements specification.

• Only user representatives can determine the correctness of user requirements.

11/7/2010 47

Feasible • It must be possible to implement each requirement within the

known capabilities and limitations of the system and its environment.

• To avoid infeasible requirements, have a developer work with the requirements analysts or marketing personnel throughout the elicitation process.

• Incremental development approaches and proof-of-concept prototypes are ways to evaluate requirement feasibility.

11/7/2010 48

PRIORITIZED• Assign an implementation priority to each functional

requirement, feature, or use case to indicate how essential it is to a particular product release.

• If all the requirements are considered equally important, it's hard for the project manager to respond to budget cuts, schedule overruns, personnel losses, or new requirements added during development.

11/7/2010 50

Unambiguous

• The reader of a requirement statement should be able to draw only one interpretation of it. – Natural language is highly prone to ambiguity– Effective ways to reveal ambiguity include:

• formal inspections of the requirements specifications, • writing test cases from requirements • creating user scenarios that illustrate the expected behavior of

a specific portion of the product.

11/7/2010 51

Requirements imprecision• Problems arise when requirements are not precisely stated.• Ambiguous requirements may be interpreted in different ways

by developers and users.• Consider the term ‘appropriate viewers for each document’

– User intention - special purpose viewer for each different document type;

– Developer interpretation - Provide a text viewer that shows the contents of the document.

11/7/2010 52

Verifiable

• See whether you can plan tests or use other verification approaches, such as inspection or formal specification, to determine whether each requirement is properly implemented in the product.

• Requirements that are not consistent, feasible, or unambiguous also are not verifiable.

11/7/2010 53

Example: VERIFIABLE

– An operator shall not have to wait for the transaction to complete… change to measureable

– An operator shall not have to wait more than 1s for a transaction to complete for at least 95% of the transactions.

Interesting phenomenon: What gets measured gets done.

11/7/2010 54

Requirements measuresProperty Measure

Speed Processed transactions/secondUser/Event response timeScreen refresh time

Size M BytesNumber of ROM 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

11/7/2010 55

Characteristics of Requirement Specification SET (SRS)

• Complete• Consistent• Modifiable• Traceable

11/7/2010 56

COMPLETE SRS• No requirements or necessary information should be absent. • Missing requirements are hard to spot because they aren't

there! • Focusing on user tasks, rather than on system functions, can

help you to prevent incompleteness.

11/7/2010 57

Consistent SRS• Consistent requirements do not conflict with other software

requirements or with higher level (system or business) requirements.

• Inconsistencies can slip in undetected if you review only the specific change and not any related requirements.

• Recording the originator of each requirement lets you know who to talk to if you discover conflicts.

11/7/2010 58

Requirements interaction• Conflicts between different non-functional requirements are

common in complex systems.• Example: Spacecraft system

– To minimise weight, the number of separate chips in the system should be minimised.

– To minimise power consumption, lower power chips should be used.

– However, using low power chips may mean that more chips have to be used. Which is the most critical requirement?

11/7/2010 59

Modifiable SRS You must be able to revise the SRS when necessary and to

maintain a history of changes made to each requirement. Each requirement be uniquely labeled and expressed separately

from other requirements so you can refer to it unambiguously. Organizing requirements so that related requirements are grouped

together. Each requirement should appear only once in the SRS. Create a table of contents, index, cross-reference listing,

traceability matrices

11/7/2010 60

Traceable SRS• A traceable requirement can be linked backward to its origin

and forward to the design elements and source code that implement it and to the test cases that verify the implementation as correct.

• Traceable requirements are uniquely labeled and are written in a structured, fine-grained way, as opposed to large, narrative paragraphs or bullet lists.

• Avoid lumping multiple requirements together into a single statement; the different requirements might trace to different design and code elements.

11/7/2010 61

Exercise 1

“The product shall provide status messages at regular intervals not less than every 60 seconds.”

Quality Analysis?

11/7/2010 62

Exercise 1: Improved

11/7/2010 63

Exercise 2

“The product shall switch between displaying and hiding non-printing characters instantaneously.”

Analysis?

11/7/2010 64

Exercise 2: Improved

“The user shall be able to toggle between displaying and hiding all HTML markup tags in the document being edited with the activation of a specific triggering condition.”

11/7/2010 65

Exercise 3“Charge numbers should be validated on-line against the

master corporate charge number list, if possible.”

Analysis?

11/7/2010 66

Exercise 3: Improved

“The system shall validate the charge number entered against the online master corporate charge number list.

If the charge number is not found on the list, an error message shall be displayed and the order shall not be accepted.”

11/7/2010 67

Problems with natural language specification of requirements

• Lack of clarity – Precision is difficult without making the document difficult to

read.• Requirements confusion

– Different types of requirements tend to be mixed-up.• Requirements amalgamation

– Several different requirements may be expressed together as a single requirement.

11/7/2010 68

Problems with NL specification of system requirements

• Ambiguity– The readers and writers of the requirement must interpret the

same words in the same way. NL is naturally ambiguous so this is very difficult.

• Over-flexibility– The same thing may be said in a number of different ways in the

specification.• Lack of modularisation

– NL structures are inadequate to structure system requirements.

11/7/2010 69

Guidelines for writing requirements• Invent a standard format and use it for all requirements.• Use language in a consistent way. Use shall for mandatory

requirements, should for desirable requirements.• Use text highlighting to identify key parts of the requirement.• Avoid the use of computer jargon.

11/7/2010 70

Alternatives to NL specification for system requirementsNotation Description

Structured natural

language

This approach depends on defining standard forms or templates to express the requirements specification.

Design description languages

This approach uses a language like a programming language but with more abstract features to specify the requirements by defining an operational model of the system.

Graphical notations

A graphical language, supplemented by text annotations is used to define the functional requirements for the system. Use-case descriptions and sequence diagrams are commonly used examples.

Mathematical specifications

These are notations based on mathematical concepts such as finite-state machines or sets. These unambiguous specifications reduce the arguments between customer and contractor about system functionality. However, most customers don’t understand formal specifications and are reluctant to accept it as a system contract.

11/7/2010 71

Structured language specifications• The freedom of the requirements writer is limited by a

predefined template for requirements.• All requirements are written in a standard way.• The terminology used in the description may be limited.• The advantage is that the most of the expressiveness of

natural language is maintained but a degree of uniformity is imposed on the specification.

11/7/2010 72

Form-based specifications• Definition of the function or entity.• Description of inputs and where they come from.• Description of outputs and where they go to.• Indication of other entities required.• Pre and post conditions (if appropriate).• The side effects (if any) of the function.

11/7/2010 73

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

11/7/2010 74

Tabular specification• Used to supplement natural language.• Particularly useful when you have to define a number of

possible alternative courses of action.

11/7/2010 75

Tabular specification

Condition Action

Sugar level falling (r2 < r1) CompDose = 0

Sugar level stable (r2 = r1) CompDose = 0

Sugar level increasing and rate ofincrease decreasing ((r2-r1)<(r1-r0))

CompDose = 0

Sugar level increasing and rate ofincrease stable or increasing. ((r2-r1) (r1-r0))

CompDose = round ((r2-r1)/4)If rounded result = 0 thenCompDose = MinimumDose

11/7/2010 76

Graphical models• Graphical models are most useful when you need to show

how the system state changes or where you need to describe a sequence of actions.

11/7/2010 77

Sequence diagrams• These show the sequence of events that take place during

some user interaction with a system.• You read them from top to bottom to see the order of the

actions that take place.• Example: Cash withdrawal from an ATM

– Validate card;– Handle request;– Complete transaction.

11/7/2010 78

Sequence diagram of ATM withdrawalATM 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

11/7/2010 79

The requirements document• The requirements document is the official statement of what

is required of the system developers.• Should include both a definition of user requirements and a

specification of the system requirements.• It is NOT a design document. As far as possible, it should be a

set of WHAT the system should do rather than HOW it should do it

11/7/2010 80

Validation Task

• During validation, the work products produced as a result of requirements engineering are assessed for quality

• The specification is examined to ensure that– all software requirements have been stated unambiguously– inconsistencies, omissions, and errors have been detected and corrected– the work products conform to the standards established for the process, the

project, and the product

• The formal technical review serves as the primary requirements validation mechanism– Members include software engineers, customers, users, and other

stakeholders

Questions to ask when Validating Requirements

• Is each requirement consistent with the overall objective for the system/product?

• Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?

• Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?

• Is each requirement bounded and unambiguous?• Does each requirement have attribution? That is, is a source

(generally, a specific individual) noted for each requirement?

(more on next slide)

Questions to ask when Validating Requirements (continued)

• Do any requirements conflict with other requirements?• Is each requirement achievable in the technical environment that

will house the system or product?• Is each requirement testable, once implemented?

– Approaches: Demonstration, actual test, analysis, or inspection

• Does the requirements model properly reflect the information, function, and behavior of the system to be built?

• Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system?

Requirements Management Task

• During requirements management, the project team performs a set of activities to identify, control, and track requirements and changes to the requirements at any time as the project proceeds

• Each requirement is assigned a unique identifier• The requirements are then placed into one or more traceability

tables • These tables may be stored in a database that relate features,

sources, dependencies, subsystems, and interfaces to the requirements

• A requirements traceability table is also placed at the end of the software requirements specification

Summary

RequirementsManagement

Validation

Inception

Elicitation

Elaboration

Negotiation

Specification

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.

– May state what the system should not do.• Non-functional requirements

– Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

– Often apply to the system as a whole rather than individual features or services.

• Domain requirements– Constraints on the system from the domain of operation

Functional requirements

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

of system where the software is used.• Functional user requirements may be high-level statements of

what the system should do.• Functional system requirements should describe the system

services in detail.

Requirements imprecision

• Problems arise when requirements are not precisely stated.• Ambiguous requirements may be interpreted in different ways

by developers and users.• Consider the term ‘search’ in requirement 1

– User intention – search for a patient name across all appointments in all clinics;

– Developer interpretation – search for a patient name in an individual clinic. User chooses clinic then search.

Requirements completeness and consistency

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

– They should include descriptions of all facilities required.• Consistent

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

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

Non-functional requirements

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

• Process requirements may also be specified mandating a particular IDE, programming language or development method.

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

Types of nonfunctional requirement

Non-functional requirements implementation

• Non-functional requirements may affect the overall architecture of a system rather than the individual components. – For example, to ensure that performance requirements are met, you

may have to organize the system to minimize communications between components.

• A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required. – It may also generate requirements that restrict existing requirements.

Non-functional classifications

• Product requirements– Requirements which specify that the delivered product must behave in a particular way e.g.

execution speed, reliability, etc.

• Organisational requirements– Requirements which are a consequence of organisational policies and procedures e.g. process

standards used, implementation requirements, etc.

• External requirements– Requirements which arise from factors which are external to the system and its development

process e.g. interoperability requirements, legislative requirements, etc.

Goals and requirements

• Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify.

• Goal– A general intention of the user such as ease of use.

• Verifiable non-functional requirement– A statement using some measure that can be objectively tested.

• Goals are helpful to developers as they convey the intentions of the system users.

Usability requirements

• The system should be easy to use by medical staff and should be organized in such a way that user errors are minimized. (Goal)

• Medical staff shall be able to use all the system functions after four hours of training. After this training, the average number of errors made by experienced users shall not exceed two per hour of system use. (Testable non-functional requirement)

Metrics for specifying nonfunctional requirements

Property Measure

Speed Processed transactions/secondUser/event response timeScreen refresh time

Size MbytesNumber of ROM 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

Domain requirements

• The system’s operational domain imposes requirements on the system.– For example, a train control system has to take into account the

braking characteristics in different weather conditions.• Domain requirements be new functional requirements,

constraints on existing requirements or define specific computations.

• If domain requirements are not satisfied, the system may be unworkable.

Domain requirements problems

• Understandability– Requirements are expressed in the language of the application

domain;– This is often not understood by software engineers developing the

system.• Implicitness

– Domain specialists understand the area so well that they do not think of making the domain requirements explicit.