requirements engineering process lecture 4. adv software engg, mscs 19, by asst prof athar mohsin,...

REQUIREMENTS ENGINEERING PROCESS

Lecture 4

Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 2

Requirements • A requirement is defined as:

– A condition or capability needed by a user to solve a problem or achieve an objective;

• A condition or a capability that must be met or possessed by a system … to satisfy a contract, standard, specification, or other formally imposed document …” IEEE 830-1993

• The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended. – Broadly speaking, software systems requirements

engineering (RE) is the process of discovering that purpose, by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation.

» Bashar Nuseibeh

Requirements Engineering• 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 Type:– User requirements

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

• Written for customers.

– System requirements• A structured document setting out detailed descriptions of the system’s

functions, services and operational constraints.

• Defines what should be implemented so may be part of a contract between client and contractor.



Challenges to Requirements • There are a number of inherent difficulties in RE process:

– Stakeholders may be numerous and distributed. – Stakholder’s goals may vary and conflicting

• Depending on their perspectives of the environment in which they work and the tasks they wish to accomplish.

– Stakeholder’s goals may not be explicit or may be difficult to articulate:

• satisfaction of these goals may be constrained by a variety of factors outside their control.

– Limitation of natural language• Ambiguity, consistency, understandability

– Writing vs reading – Verity of methods– Controlling/ managing/ tracing changes – validation


Challenges to Requirements• So Many “Requirements”…

– A goal is an objective or concern used to discover and evaluate functional and non-functional requirements.

• A goal is not yet a requirement…– A functional requirement is a requirement defining functions of the

system under development• Describes what the system should do

– A non-functional requirement is a requirement characterizing a system property such as expected performance, robustness, usability, maintainability, etc.

• Constraints that must be adhered to during development – A user requirement is a desired goal or function that a user and other

stakeholders expect the system to achieve• Does not become necessarily a system requirement

– A domain requirement is a requirement derived from the application domain

• Can be functional or non-functional– Product Requirement– Process requirement– Security Requirements


Challenges to Requirements

• Elicitation Risks and Challenges– Problems of scope

• System boundaries inadequately defined or defined too soon

• Unnecessary technical details

– Problems of understanding• Stakeholder not sure of what is needed

• Stakeholder has trouble communicating needs

• Stakeholder does not understand capabilities and limitation of computing environment

• Stakeholder does not have full understanding of domain

• Stakeholders state conflicting requirements

– Problems of volatility• Stakeholders will not commit to a set of written requirements


Challenges to Requirements

• Elicitation Risks and Challenges– Other typical issues

• Experts seldom available• Finding an adequate level of precision/detail• Common vocabulary often missing• Sometimes hidden• Sometimes too obvious, implicit, ordinary…

– Participants often lack motivation and resist to change

• We need much efforts and discussion to come up with a common agreement and understanding


Software Requirement- SWEBOK


Requirements Engineering • “Requirements engineering is the branch of software

engineering concerned with the “REAL-WORLD GOALS” for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to “PRECISE SPECIFICATIONS” of software behavior, and to their EVOLUTION OVER TIME AND ACROSS SOFTWARE FAMILIES.”– Real world Goals: Motivate the development of a software

system.• Represent the ‘why’ and ‘what’ of a system.

– Precise Specification: Provide the basis for:• Analyzing requirements, • Validating (what stakeholders want),• Defining what designers have to build, and • Verifying that they have done so correctly upon delivery

– Evolution over Time: Emphasizing the reality of a changing world and the need to reuse partial specifications,


Software requirements engineering • Process of determining what is to be produced in a

software system• An important aspect of any software project, and is

a general term used to encompass all the activities related to requirements. – The four specific steps in software requirements

engineering are: • Requirements Elicitation • Requirements Analysis • Requirements Specification • Requirements Validation

Seems to be separate tasks but these four processes cannot be strictly separated and performed sequentially and repeatedly


RE Activities• Requirements elicitation

– Requirements discovered through consultation with stakeholders

• Requirements analysis and negotiation– Requirements are analyzed and conflicts resolved

through negotiation

• Requirements specification– A precise requirements document is produced

• Requirements validation– The requirements document is checked for consistency

and completeness

• Requirements management– Needs and contexts evolve, and so do requirements!

Acknowledgement to the work of Karl Wiegers, Software Requirements

Acknowledgement to the work of Karl Wiegers, Software Requirements


•(Martin & Leffinwell)

Distribution of Effort to Fix Defects

Code7% Other

10%

Design27%

Requirements56%

Code1%

Other4%

Design13%Requirements

82%

Distribution of Defects

Why Focus on Requirements

•NIST (National Institute of Standards and Technology's)–70 % of the defects are introduced in the specification

phase –30 % are introduced later in the technical solution process. –Only 5 % of the specification inadequacies are corrected in

the specification phase –95 % are detected later in the project or after delivery

where the cost for correction in average is 22 times higher compared to a correction directly in the specification effort.

• The NIST report concludes that extensive testing is essential, however testing detects the dominating specification errors late in the process.


Standish CHAOS Report -2010 – “This year’s results show a marked decrease in project

success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions”

– Jim Johnson, chairman of The Standish Group says:• “44% were challenged which are late, over budget, and/or with

less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used.”

– Five of the eight main factors for project failure deal with requirements:

• incomplete requirements,• low customer involvement, • unrealistic expectations, • changes in the requirements,• and useless requirements.


Time

Why?

What?

How?

Who?When?

If-Then

Does It?

Where?

Project Management Process

Quality Management Process

Component & Configuration Management Process

Risk Management Process

Identify Business Needs and Goals

Derive User & Functional Requirements

Design Solutions

TIME

RE Process and Related Activities

• Whether viewed at the systems level or the software level, RE is a multi-disciplinary, human-centred process. – The tools and techniques used in RE draw upon a variety of

disciplines, and the requirements engineer may be expected to master skills from a number of different disciplines.

• RE must span the gap between the informal world of stakeholder needs, and the formal world of software behaviour, the key question over the use of formal methods is not whether to formalise, but when to formalise


Why• “If you don’t get the requirements right, it doesn’t matter how

well you do anything else.” One can end up doing a perfect job of building the wrong product.

» Karl Wiegers (2004)

• Issues that can have a negative impact– Incomplete requirements:

• A software product that does not meet all of the customer and user’s needs.

– Lack of user involvement: • if practitioners miss a stakeholder group

– Requirements mix: • changes in the requirements after initially agreement, missing, poorly

written or ambiguous requirements– Wasted resources:

• Requirements errors results in 70-85 percent of the rework– Gold plating:

• Developer adds functionality that was not in the requirements specification

– Inaccurate estimates: • Requirement defines the scope, scope help is schedule and cost

estimation


“What”- Part of the Requirements

• Requirements must be determined and agreed to by the customers, users, and suppliers of a software product before the software can be built.

• The requirements define the “what” of a software product:– What the software must do to add value for its stakeholders.

• These functional requirements define the capabilities of the software product.

– What the software must be to add value for its stakeholders. • These nonfunctional requirements define the characteristics, properties,

or qualities that the software product must possess.

• They define how well the product performs its functions.

– What limitations there are on the choices that developers have when implementing the software.

• The external interface definitions and other constraints define these limitations.

Why the Software is being developed


Who• Stakeholders who affect or are affected by the

software product and therefore have some level of influence over the requirements for that software product.– The RE process consider all of the various stakeholder’s

interest in context with one another.– Stakeholders

• Acquirers– Purchasers & end users

• Suppliers– Organization & Developers (requirement Analyst, designer,

Developers, Testers & technical writer

• Others– Legal or contract management, Government or regulator agencies &

Society at large


Who• The first step in identifying the stakeholders is to

make sure that one considers all of the potential stakeholders.

• The following checklist can help in identifying potential stakeholders:– What types of people will use the software product?– What business activities are supported by the software

product and who performs, or manages those activities?– Whose job will be impacted by the introduction of the new

software product?– Who will receive the reports, outputs, or other information

from the software product?– Who will pay for the software product?


Software Requirement- SWEBOK• Requirements Process

– Process Actors• Stakeholders

• Process Support and Management

– make the link between the process activities and the issues of cost, human resources, training, and tools.

• Requirements Sources– Goals.

• (sometimes called ‘business concern’ or ‘critical success factor’)

refers to the overall, high-level objectives of the software.– Domain knowledge.

– Stakeholders

– The operational environment.

– The organizational environment.

– Similar System

– Documents / regulation / SOPs


How• Software requirements engineering is a disciplined, process-

oriented approach to the definition, documentation, and maintenance of software requirements throughout the software development life cycle.– software requirements engineering is made up of two major processes:

requirements development and requirements management.


How part of Requirements • Requirements Engineering: A Roadmap, Bashar Nuseibeh

– The context in which RE takes place is usually human activity system and the problem owner are people.

– Techniques for eliciting and modeling, drawn on cognitive and social sciences:

• Cognitive Psychology– Provides an understanding of the difficulties people may have in describing

their needs» domain experts often have large amounts of knowledge their answers to

questions posed by requirements analysts may not match their behaviour.

• Anthropology– Provides a methodological approach to observing human activities that helps

to develop a richer understanding

• Sociology– Provides an understanding of the political and cultural changes caused by

computerization.

• Linguistics– To avoid ambiguity and to improve understandability.

Eliciting Requirements• Requirements to Elicit

– Boundaries• Identify the high level boundaries of

the system• Stakeholders and Use Cases

depend on boundaries

– Goals• Denote the OBJECTIVES a system

must meet.• Eliciting High level goals early in

development– High level goals (business goals)

refined into lower level goals (technical goals) eventually operationalised in a system

– Tasks• When it is difficult to articulate user

requirements– Observe, case studies, scenarios

• Elicitation Techniques– Traditional Techniques

• Questionnaires and Surveys• Interviews• Analysis of existing

documentation

– Group Elicitation• Group brainstorming

sessions• RAD (Rapid Application

Development)• JAD (Joint Application

Design)

– Prototyping• Where there is great deal of

uncertainty• Early feedback from

stakeholders is needed



Sources of Requirements• Various stakeholders

– Clients, customers, users (past and future), managers, domain experts, developers, marketing and QA people, lawyers, auditors, anyone who can bring added value!

• Pre-existing systems– Not necessarily software systems

• Pre-existing documentation• Competing systems• Documentation about interfacing systems• Standards, policies, collective agreements,

legislation


Comparison of some techniquesTechnique Good for Kind of data Plus Minus

Questionnaires Answering specific questions

Quantitative and qualitative data

Can reach many people with low

resource

The design is crucial. Response rate may be low.

Responses may not be what you want

Interviews Exploring issues Some quantitative but mostly

qualitative data

Interviewer can guide interviewee.

Encourages contact between developers

and users

Time consuming. Artificial

environment may intimidate

interviewee

Focus groups and workshops

Collecting multiple viewpoints

Some quantitative but mostly

qualitative data

Highlights areas of consensus and

conflict. Encourages contact between developers and

users

Possibility of dominant characters

Naturalistic observation

Understanding context of user

activity

Qualitative Observing actual work gives insight

that other techniques cannot

give

Very time consuming. Huge amounts of data

Studying documentation

Learning about procedures,

regulations, and standards

Quantitative No time commitment from

users required

Day-to-day work will differ from

documented procedures

Acknowledgment: Preece, Rogers, and Sharp “Interaction Design: Beyond human-computer interaction”, p214


Software Requirement- SWEBOK• Product Requirements

– Requirements on software to be developed• The software shall verify that a student meets all prerequisites

before he or she registers for a course

• Process Requirements– A constraint on the development of the software

• The software shall be written in C#.

– Imposed directly by the development organization, their customer, or a third party such as a safety regulator

• Functional Requirements

– Describe the functions that the software is to execute – AKA Capabilities

• Non-Functional Requirements

– The ones that act to constrain the solution AKA Constraints


Software Requirement- SWEBOK• Emergent Properties

– Requirements which cannot be addressed by a single component, but which depend for their satisfaction on how all the software components interoperate.

• Quantifiable Requirements– To avoid vague and unverifiable requirements which

depend for their interpretation on subjective judgment• The software shall be reliable’• ‘The software shall be user-friendly’

• System Requirements– An interacting combination of elements to accomplish a

defined objective.

• Software requirements are derived from system requirements.


Functional Requirements – What inputs the system should accept– What outputs the system should produce– What data the system should store that other

systems might use– What computations the system should perform– The timing and synchronization of the above – Examples:

• The user shall be able to search either all of the initial set of databases or select a subset from it.

• The system shall provide appropriate viewers for the user to read documents in the document store.

• A user shall be able to search the appointments lists for all clinics.

• The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day.

• Each staff member using the system shall be uniquely identified by his or her 8-digit employee number.


Non-functional classifications• Product requirements

– Requirements which specify that the delivered product must behave in a particular way • e.g. execution speed, reliability, etc.

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

• Organisational requirements– Requirements which are a consequence of organisational policies

and procedures • e.g. process standards used, implementation requirements, etc.

– The system development process and deliverable documents shall conform to the process and deliverables defined in organization’s mission statement

• External requirements– Requirements which arise from factors which are external to the

system and its development process• e.g. interoperability requirements, legislative requirements, etc.

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

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organisationalrequirements

Externalrequirements

Non-functionalrequirements

Metrics for specifying nonfunctional requirements

Property Measure

Speed Processed transactions/secondUser/event response time/ Screen refresh time

Size MbytesNumber of ROM chips

Ease of use Training timeNumber of help frames

Reliability Mean time to failure / AvailabilityProbability of unavailabilityRate of failure occurrence

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.

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


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 following requirement– A user shall be able to search the appointments lists for

all clinics.• 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.


The software requirements document• The software 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 set of WHAT the system

should do rather than HOW it should do it.


Requirements specification• The process of writing the user and system

requirements in a requirements document.– User requirements have to be understandable by end-

users and customers who do not have a technical background.

– System requirements are more detailed requirements and may include more technical information.

• The requirements may be part of a contract for the system development– It is therefore important that these are as complete as

possible.


Ways of writing a system requirements specification

Notation Description

Natural language The requirements are written using numbered sentences in natural language. Each sentence should express one requirement.

Structured natural language

The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement.

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. This approach is now rarely used although it can be useful for interface specifications.

Graphical notations Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used.

Mathematical specifications

These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract


Structure of a Good Requirement

“The system shall allow the Internet user to accesshis current account balance in less than 5 seconds.”

Defines a positive end result Performance criteria

Defines a subject Shall or should verb

•This requirement sentence identifies a specific subject and end result that is wanted within a specified time that is measurable.

– The challenge is to seek out the subject, end result, and success measure in every requirement you define!


“The Internet user quickly sees the balance of heraccount on the laptop screen .”

Cannot write a requirement on the user

Vague quality criterion What versus how

No identifier for the verb

Example of a Bad Requirement


Standard for Writing a Requirement–Each requirement must first form a complete sentence

• Not a bullet list of buzzwords–Each requirement contains a subject and predicate

• Subject: a user type or the system under discussion• Predicate: a condition, action, or intended result.

–Consistent use of the verb:• “shall,” “will”, or “must” to show mandatory nature• “should” or “may” to show optionality• Usually, shall and should are used.

–A requirement contains a success criterion or other measurable indication of the quality.

–A requirement describes what must be done, rather than how.


Writing errors to Avoid

•Never describe how the system is going to achieve something (over-specification), always describe what the system is supposed to do

–Refrain from designing the system• Danger signs: using names of components, materials,

software objects, fields & records in the user or system requirements

–Designing the system too early may possibly increase system costs

–Do no mix different kinds of requirements (e.g., requirements for users, system, and how the system should be designed, tested, or installed)

–Do not mix different requirements levels (e.g., the system and subsystems)• Danger signs: high level requirements mixed in with

database design, software terms, or very technical terms



•“What versus how” test

The system shall use Microsoft Outlook to send an email to the customer with the purchase confirmation.

The system shall inform the customer that the purchase is confirmed.

X


Writing errors to Avoid•Never build in let-out or escape clauses

–Requirements with let-outs or escapes are dangerous because of problems that arise in testing

–Danger signs: if, but, when, except, unless, although• These terms may however be useful when the

description of a general case with exceptions is much clearer and complete that an enumeration of specific cases

•Avoid ambiguity–Write as clearly and explicitly as possible–Ambiguities can be caused by:

• The word or to create a compound requirement• Poor definition (giving only examples or special cases)• The words etc, …and so on (imprecise definition)



•Do not use vague indefinable terms–Many words used informally to indicate quality are too vague

to be verified–Danger signs: user-friendly, highly versatile, flexible, to the

maximum extent, approximately, as much as possible, minimal impact

The Easy Entry System shall be easy to use and requirea minimum of training except for the professional mode.

X


Writing errors to Avoid•Do not make multiple requirements

–Keep each requirement as a single sentence–Conjunctions (words that join sentences together) are

danger signs: and, or, with, also

•Do not use–Long sentences with arcane language –References to unreachable documents

The Easy Entry Navigator module shall consist of order entry and communications, order processing, result processing, and reporting. The Order Entry module shall beintegrated with the Organization Intranet System and results are stored in the group’s electronic customer record.

X


Writing errors to Avoid•Do not speculate

– There is no room for “wish lists” – general terms about things that somebody probably wants

– Danger signs: vague subject type and generalization words such as usually, generally, often, normally, typically

•Do not express suggestions or possibilities– Suggestions that are not explicitly stated as requirements are

invariably ignored by developers– Danger signs: may, might, should, ought, could, perhaps,

probably•Avoid wishful thinking

– Wishful thinking means asking for the impossible (e.g., 100% reliable, safe, handle all failures, fully upgradeable, run on all platforms)

The Easy Entry System may be fully adaptable to all situations and often require no reconfiguration by the user.

X


Requirements problem example

• “LIBSYS will be configurable so that it will comply with the requirements of international copyright legislation. Minimally, this means that LIBSYS must provide a form for the user to sign the Copyright Declaration statement. It also means that LIBSYS must keep track of Copyright Declaration statements which have been signed/not-signed. Under no circumstances must an order be sent to the supplier if the copyright statement has not been signed.”

Dig out the problems in this requirement


Problems in example requirement • Incompleteness

– What international copyright legislation is relevant?– What happens if the copyright declaration is not signed?– If a signature is a digital signature, how is it assigned?– Recommendation:

• Define all copyright legislation as a separate requirement

• Reword requirement as “ copyright declaration must be signed before order is complete

• Introduce a new requirement for signature assignment

• Ambiguity– What does signing an electronic form mean? Is this a physical

signature or a digital signature?• Define what is meant by “signature”

• Standards– More than 1 requirement. Maintenance of copyright is one

requirement; issue of documents is another• Split the requirements in two or three separate requirements


Acknowledgement • SWEBOK Chapter 4• Requirements Engineering: A Roadmap

– Bashar Nuseibeh

• Software Requirements Engineering: What, Why, Who, When and How– Linda westfall

• Chapter 4 Software Engineering 9th edition – Ian Sommerville

• Requirements Engineering – Kotonya & Sommerville

requirements engineering process lecture 4. adv software engg, mscs 19, by asst prof athar mohsin,...

Documents

system requirements

nonfunctional requirements

requirements type

system services

domain requirement

user requirements statements

system property

adv software engg