Requirement engineering in S/W Engineering

Requirements Engineering

K.T.Mikel Raj

Requirements and systems

User world

Software-based system

Requirements

Photo © Liam Quinn

What are system requirements?• Requirements are defined during the early stages of a

system development as a specification of what should be implemented or as a constraint of some kind on the system.

• They may be:– a user-level facility description, – a detailed specification of expected system behaviour,– a general system property, – a specific constraint on the system,– information on how to carry out some computation,– a constraint on the development of the system.

What is requirements engineering?• Requirements engineering covers all of the activities

involved in discovering, documenting, and maintaining

a set of requirements for a computer-based system.

• The use of the term ‘engineering’ implies that

systematic and repeatable techniques should be used

to ensure that system requirements are complete,

consistent, relevant, etc.

What happens if the requirements are wrong? The system may be delivered late and cost

more than originally expected.

The customer and end-users are not satisfied

with the system. They may not use its facilities

or may even decide to scrap it altogether.

The system may be unreliable in use with

regular system errors and crashes disrupting

normal operation.

If the system continues in use, the costs of

maintaining and evolving the system are very

high.

Why is RE difficult?• Changing environments

– Businesses operate in a rapidly changing environment so their requirements for system support are constantly changing.

• Differing views– Multiple stakeholders with different goals and priorities are

involved in the requirements engineering process.• Unclear opinions

– System stakeholders do not have clear ideas about the system support that they need.

• Politics and people– Requirements are often influenced by political and

organisational factors that stakeholders will not admit to publicly.

Requirements engineering Terminology

Terms that you should understandStakeholders

Viewpoints

concerns

Stakeholders• People or roles who are affected, in some way,

by a system and so who can contribute requirements or knowledge to help you understand the requirements

• Example – medical system stakeholders– Doctors– Nurses– Patients– Hospital managers– Administrators – Owners of other connected systems

Viewpoints• Viewpoints are a way of organizing and

grouping requirements that have been elicited from stakeholders

• The requirements generally represent the views and needs of a class or type of stakeholder

• Examples of viewpoints– End-user viewpoint– Managerial viewpoint– System administration viewpoint– Engineering viewpoint

Stakeholders and viewpoints

Stakeholders

Requirements

VP1VP2

VP4VP3

Provide information about

Concerns• Are issues that an organization must pay

attention to and that are systemic i.e. they apply to the system as a whole

• They are cross-cutting issues that may affect all system stakeholders and the requirements from these stakeholders

• Concerns help bridge the gap between organizational goals (what the organization has to achieve) and system requirements (how a system contributes to these goals)

Concerns

Software and hardware

Operators and managers

Society

The organization

SafetyAvailabilitySecurity

Requirements engineering processes

Different views of the processes involved in requirements engineering

The systems engineering process

RE process context

RE process inputs and outputs

RE process activities

RE process iteration

Requirements engineering problems

Fundamental issues that mean that establishing requirements for complex systems will always be a difficult technical and organisational problem

Requirements change

• System requirements reflect the world outside of the system. As this is constantly changing then the requirements will inevitably also changeTechnology changesOrganisational changesMarket changesEconomic changesPolitical and legal changes

• It is often difficult to understand the implications of changes for the requirements as a whole

Stakeholder perspectives

The problem and the required system

Social perspectiveTechnical perspective

ObjectsFunctionsRoles ...

User perspectiveInteractionsUsability Management perspective

Certificationperspective

Customerperspective

Stakeholder uncertainty

• Key stakeholders have other jobs to do!– Developing detailed requirements for future systems often

cannot be given a high priority by the senior people who will be affected by these requirements.

– They therefore are unable to express their requirements except as vague, high-level descriptions

The requirements engineering process

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument

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.

Feasibility study implementation

• Based on information assessment (what is required), information collection and report writing.

• Questions for people in the organisation– What if the system wasn’t implemented?– What are current process problems?– How will the proposed system help?– What will be the integration problems?– Is new technology needed? What skills?– What facilities must be supported by the proposed

system?

Understanding Requirements• Collecting needs from the customer.• Managing the Process.• Tasks involved:

InceptionElicitationElaborationNegotiationSpecificationValidationRequirements Management

28

RequirementsManagement

Validation

Inception

Elicitation

Elaboration

Negotiation

Specification

• During inception, the requirements asks a set of questions to establish:– Basic understanding of the

problem.– Nature of the solution that is

desired.• Requirements Engineers needs to

Identify the stakeholders, recognize multiple viewpoints, work toward collaboration and initiate the communication.

Inception (Beginning)

30


Validation

Inception

Elicitation

Elaboration

Negotiation

Specification

Eliciting requirements is difficult because of Problems of scope identify the boundaries of the system. Problems of understanding domain , computing

environment. Problems of Volatility requirements may change over time. Elicitation may be accomplished through two activities:

Collaborative Requirements GatheringQuality Function Deployment.

Elicitation: (Extraction)

32


Validation

Inception

Elicitation

Elaboration

Negotiation

Specification

• Takes the information obtained during

inception and elicitation.

• Focuses on developing a refined model

of software functions, features &

Constraints.

• This is an analyzing phase.

• It defines the functional, informational

and behavioral constraints of the

problem domain.

Elaboration (explanation)

34


Validation

Inception

Elicitation

Elaboration

Negotiation

Specification

Software engineer reconciles the

conflicts between what the

customer wants and what can be

achieved.

Requirements are ranked by the

customer, users and other

stakeholders.

Risks associated with each

requirement are identified.

Negotiation (Cooperation)

36


Validation

Inception

Elicitation

Elaboration

Negotiation

Specification

Final work product produced by the requirements engineer.

Form of SRS.Serves as a foundation.It formalizes the functional and

behavioral requirements of the proposed software in both the graphical and textual format.

Specifications

38


Validation

Inception

Elicitation

Elaboration

Negotiation

Specification

Specification is examined to ensure that all the sw requirements have been stated unambiguously.

Errors have been detected and corrected.

Members involved:Software EngineersCustomersUsersOther stakeholders.

Validation

Requirements checking

• Validity. Does the system provide the functions which best

support the customer’s needs?

• Consistency. Are there any requirements conflicts?

• Completeness. Are all functions required by the customer

included?

• Realism. Can the requirements be implemented given available

budget and technology

• Verifiability. Can the requirements be checked?

41


Validation

Inception

Elicitation

Elaboration

Negotiation

Specification

Project team performs a set of activities to identify, control and track

requirements and changes to the requirements at any times as the project

proceeds.

Each requirement is assigned a unique identifier.

Place the requirements into one or traceability tables.

Tables may be stored in a database that relate features, sources,

dependencies subsystems and interfaces to the requirements.

Requirements Management