MODULE II

Modeling Knowledge
(Requirement Engineering)
 Topic covered

Understanding requirements

Requirement Engineering
 Understanding Requirements

To understand what the customer wants before you begin to design and build a
computer-based system.
Understanding problem requirements is the most difficult tasks facing software
engineer.
 By establishing a set of requirements, you will gain an understanding of what
the impact of the software will be, what the customer wants and how end uses
will interact with the software.
 Questions for Requirements

Ask questions to the customer, the user and others..

 What the objectives for the system or product are?
 What is to be accomplished?
 How the system or product fits into the needs of the business?
 How the system or product is to be used on a day-to day basic?
It is not simple, it is not very hard.
 Requirement Engineering
 Requirement engineering is the process of defining, documenting and maintaining the requirements. 
 The process of establishing the services that a customer requires from a system and the constraints under
which it operates and is developed.
 Software engineers and other project stakeholders (managers, customers and end users) all participate in
requirement engineering.
 The work product (output) may include usage scenarios, function and feature lists and requirement models.
 Without requirement engineering, the resulting software has a high probability of not meeting customer’s
needs
 Requirement Engineering Steps

1) Inception
2) Elicitation
3) Elaboration
4) Negotiation
5) Specification
6) Validation
7) Requirement Management
 (1) Inception

Most projects begin with an identified business need or what a potential new
market or service is discovered.
Establish a basic understanding of the problem, the people who want a solution
and the nature of the solution that is desired.
Communication between all stakeholders and the software team needs to be
established during this tasks.
 (2) Elicitation
 Important part of elicitation is to understand the business goals.
 A goal is a long-term aim that a system or product must achieve.
 Goals may be either functional or non-functional (reliability, usability, security) concerns.
 Goals are good ways to explain requirements to stakeholder.
 Goals should be specified precisely and serve as the basic of requirement elaboration,
verification and validation, conflict management, negotiation, explanation an evolution.
 Your job is to engage stakeholders and to encourage them to share their goals honestly.
 Once goals are captured establish prioritization mechanism and create design for potential
architecture.
 (2) Elicitation (Cont’d)
Agility is important aspect of RE.
The intent of elicitation is to transfer ideas from the stakeholders to the software
term smoothly and without delay.
If new requirements are emerges then iterative development process occurs.
 Problems of Requirements Elicitation
Stakeholders don’t know what they really want.
Stakeholders express requirements in their own terms.
Different stakeholders may have conflicting requirements.
Organisational and political factors may influence the system requirements.
The requirements change during the analysis process. New stakeholders may emerge
and the business environment may change.

10
 Requirements Discovery

The process of gathering information about the required and existing systems and
distilling the user and system requirements from this information.
Interaction is with system stakeholders from managers to external regulators.
Systems normally have a range of stakeholders.

11
 Interviewing
Formal or informal interviews with stakeholders are part of most RE processes.
Types of interview
 Closed interviews based on pre-determined list of questions
 Open interviews where various issues are explored with stakeholders.

Effective interviewing
 Be open-minded, avoid pre-conceived ideas about the requirements and are willing to listen to
stakeholders.
 Prompt the interviewee to get discussions going using a springboard question, a requirements
proposal, or by working together on a prototype system.
12
 Interviews in practice
Normally a mix of closed and open-ended interviewing.
Interviews are good for getting an overall understanding of what stakeholders do and
how they might interact with the system.
Interviewers need to be open-minded without pre-conceived ideas of what the system
should do
You need to prompt the use to talk about the system by suggesting requirements
rather than simply asking them what they want.

13
 Problems with interviews
Application specialists may use language to describe their work that isn’t easy for the
requirements engineer to understand.
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.

14
 (3) Elaboration

• Focus on developing a refined requirements model that identifies various aspects of software
functions, behavior and information.
• Driven by the creation and refinement of user scenarios ( describe how the end users, actors will
interact with the system) obtained during elicitation.
• Each user scenario is passed to extract analysis classes – business entities that are visible to the
end user–
• Then attributes, services and relationships of each class are identified.
• But you need to know when to stop.
 (4) Negotiation
• Different customers or users to propose conflicting requirements, arguing that their vision is”
essential for our special needs”
• The conflicts need to reconciled.
• Need to asked to rank requirements and then discuss conflicts in priority.
• No winner or no loser in an effective negotiation.
• Both side win because of dealing requirements conflict.
• Use an iterative approach that prioritizes requirements, accesses their cost and risk, and addresses
internal conflicts.
• In this ways, requirements are eliminated, combined and/ or modified that are to meet the user
satisfaction.
 (5) Specification

• Means different things to different people.

• A specification can be written document, a set of graphical models, a formal mathematical
model, a collection of usage scenarios, a prototype or any combination of these.
• Sometimes necessary to remain flexible when a specification is developed.
 (6) Validation

• The work product produced from RE are accessed for quality during validation steps.
• Aim is requirement consistency.
• Examines the specification to ensure that all software requirements have been stated unambiguously; that
inconsistencies, omissions and errors have been detected and corrected; that the work product conforms to
standards.
• The primary method is the technical review.
• The review team validates requirements includes software engineers, customers, users and other stakeholders
who examines the specification looking for errors, missing information, inconsistencies, conflicting
requirements or unrealistic (unachievable) requirements.
 (6) Validation (Cont’d)

To illustrate problems that occurs during requirements validation, here are examples
 The software should be user friendly.
 The probability of a successful unauthorized database intrusion should be less than 0.0001.
(1) 1st requirement is too vague for developers to test or asses. User friendly means? (quantified or
qualified)
(2) 2nd requirement is quantitative but intrusion testing will be difficult and time consuming.
Is this level of security even warranted for the application?
 (7) Requirement Management

• Requirement management is needed for changing requirements.

• It is a set of activities that help the project team identify, control and track requirements and
changes to requirements at any time as the project proceeds.
End of Lecture
PRACTICAL DISCUSSION