REQUIREMENT PROCESS

CUONG V. NGUYEN - SE 2020

REQUIREMENT PROCESS
Consists of following activities:
▪ requirements discovery and analysis
▪ requirements validation
▪ requirements management

In practice, it is an iterative process in which these activities are interleaved.

CUONG V. NGUYEN - SE 2020

REQUIREMENTS DISCOVERY
▪ Technical staff working with stakeholders and domain experts to find out
about the problem domain, requirements and constraints
Activities:
▪ Requirements classification and organization
▪ Prioritization and negotiation
▪ Requirements specification

CUONG V. NGUYEN - SE 2020

CONFLICT OF KNOWLEDGE
▪ Stakeholders don’t know what they really want.
▪ Stakeholders express requirements in their own terms.
▪ Different stakeholders may have conflicting requirements.
▪ Organizational 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.

CUONG V. NGUYEN - SE 2020

REQUIREMENT DISCOVERY TECHNIQUES
▪ Interviewing business stakeholders
▪ Powerful questions
▪ Sketching
▪ Rapid prototyping
▪ Event storming

CUONG V. NGUYEN - SE 2020

INTERVIEWING STAKEHOLDERS
types of interviews
▪ closed interviews
▪ open interviews
effective interviewing
▪ be open-minded
▪ avoid preconceived ideas
▪ prompt interviewees
▪ ask powerful questions
▪ proposal requirements
▪ shows sketches and rapid prototypes

CUONG V. NGUYEN - SE 2020

INTERVIEWING - POWERFUL QUESTIONS
Three phases:
1. “Context free” questions: focused on the customer and other stakeholders, the
overall project goals and benefits:
▪ Who is behind the request for this work?
▪ Where does the need of this system come from?
▪ Who will use the solution?
▪ How will this system give value to the business?
▪ What will be the economic benefit of a successful solution?
▪ What would happen if this system wasn’t built?
▪ Is there another source for the solution that you need?

CUONG V. NGUYEN - SE 2020

POWERFUL QUESTIONS
2. Understand the problem: allow customer to voice her perceptions about a
solution:
▪ How would you characterize “good” output that would be generated by a
successful solution?
▪ What problems will this solution address?
▪ Can you show me (or describe) the business environment in which the solution
will be used?
▪ What is the problem with your existing software system?
▪ Will special performance issues or constraints affect the way the solution is
approached?
CUONG V. NGUYEN - SE 2020
POWERFUL QUESTIONS
3. Validation: focus on the effectiveness of the communication activity itself:
▪ 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?

CUONG V. NGUYEN - SE 2020

POWERFUL QUESTIONS
1. The question is short and precise.
▪ powerful question is nearly always a short one. It is easy to remember and
easily understandable. But do not over shorten it – the most important
thing is that it is clear.
▪ Good example: “What will be the impact of this change to ?”
1. The question is a single one.
▪ A powerful question is usually a single question – not multiple questions
wrapped up in a single sentence
▪ Good example: “What are the barriers to knowledge sharing in our
organization and how might we overcome them?”
CUONG V. NGUYEN - SE 2020
POWERFUL QUESTIONS
The question is open-ended.
▪ A powerful question is never a closed one but an open-ended one.
▪ Bad example: Should we go ahead with the new branding exercise?
▪ Good example: What should we do next?

The question is not a leading one.

▪ A leading question is a question which subtly prompts someone to answer in a
particular way.
▪ Bad example: What are the problems with the new system?
▪ Good example: What do you think of the new system?

CUONG V. NGUYEN - SE 2020

POWERFUL QUESTIONS
It engages people and provokes them to think deeply.
▪ Good example: What are the key factors in making this decision?
The question is provocative or a little unsettling.
▪ It is one that slightly annoys or enthuses people depending on their values or
beliefs.
▪ Good example: When we compete on price, are we revealing a lack of
faith in the value our products deliver to customers?

CUONG V. NGUYEN - SE 2020

FOLLOWING UP
▪ Interviews should be used for the first encounter only.
▪ Define use cases and their scenarios as the next step on the base of the
information gathered from the interviews.
▪ Talk again to the stakeholders and domain experts.
▪ Try to understand the problem domain.

CUONG V. NGUYEN - SE 2020

SKETCHING
▪ visual representation in a form of informal sketches can enhance
communication with stakeholders and domain experts
▪ it is not necessary to use more formal UML diagrams
▪ you can discuss UML diagrams later with the stakeholders and domain
experts for validation and complementing details

CUONG V. NGUYEN - SE 2020

RAPID PROTOTYPING
▪ people like rapid prototypes in a form of screen mock-ups
▪ prototype is a pre-initial version of a software which demonstrates concepts
▪ prototype may be even hand-drawn screens

CUONG V. NGUYEN - SE 2020

EVENT STORMING
▪ workshop which helps to quickly build an understanding of the problem
domain
▪ participants are domain experts, stakeholders and the development team
▪ large space for visual modeling is provided
▪ people model their business and their problem domain using colored stickers
representing domain events, commands and aggregates

CUONG V. NGUYEN - SE 2020

BUILDING THE SPECS
▪ Requirements discovery and analysis usually results in one or more of the
following types of models
▪ scenario-based
▪ information-oriented
▪ flow-oriented
▪ Behavioral
This is where tools like UML diagrams became handy.

CUONG V. NGUYEN - SE 2020

VALIDATION
▪ 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, tested?
▪ Comprehensibility. Is the requirement properly understood?
▪ Traceability. Is the origin of the requirement clearly stated?
▪ Adaptability. Can the requirement be changed without a large impact on other
requirements?
CUONG V. NGUYEN - SE 2020
VALIDATION TECHNIQUES
▪ Requirements reviews
▪ Prototyping
▪ Test-case generation

CUONG V. NGUYEN - SE 2020

ITERATION
The business and technical environment of the system always changes. New
legislation and regulations.
▪ Regular reviews should be held while the requirements definition is being
formulated.
▪ Stakeholders, domain experts and the development team should be involved
in reviews.
▪ Reviews may be formal (with completed documents) or informal. Good
communications between developers, customers and users can resolve
problems at an early stage.

CUONG V. NGUYEN - SE 2020

COMMON ISSUES
▪ Ambiguous – They have several different meanings or interpretations
▪ Incomplete – Simply, they don’t cover everything that needs to be addressed with
the product or system solution
▪ Inconsistent – Parts of the requirements negate information in other requirements
▪ Out of date – They haven’t been updated since new needs have been identified or
new functionality has been included
▪ Too technical – Requirements are not in the language of the end users or
stakeholders, thus errors and misunderstandings occur
▪ Not prioritized – Nice-to-have functionality is mixed in with must-have functionality
▪ Irrelevant – They provide for features that are not needed in the final solution

CUONG V. NGUYEN - SE 2020

BEST PRACTICES
Customers don't (really) know what they want
▪ spend sufficient time at the start of the project on understanding the objectives,
deliverables and scope of the project
▪ Get your customer to read, think about and sign off on the completed software
requirements
Requirements change during the course of the project
▪ Have a clearly defined process for receiving, analyzing and incorporating change
requests
▪ Set milestones for each development phase
▪ Ensure that change requests (and approvals) are clearly communicated to all
stakeholders

CUONG V. NGUYEN - SE 2020

BEST PRACTICES
Communication gaps
▪ Take notes at every meeting
▪ Be consistent in use of words, make sure the definitions of terms are the
same, ensure all stakeholders have a copy, and stick to them consistently.
▪ Build relationships and maintain contacts with the information holders.

CUONG V. NGUYEN - SE 2020

SUMMARY
▪ Requirement engineering process consists of following activities:
 requirements discovery and analysis
 requirements validation
 requirements management

▪ Requirement discovery techniques such as powerful questions, rapid

prototyping.
▪ Iteration mindset for validation and change management.

CUONG V. NGUYEN - SE 2020