(II) Modeling Knowledge (RE)
(II) Modeling Knowledge (RE)
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
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
• 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