1. ELICITATION & ANALYSIS
REQUIREMENTS
ELICITATION & ANALYSIS
9/17/2019

2. Outline Objectives and basic concepts Requirement engineering process
Requirement engineering metrics
Challenges
9/17/2019

3. Aim of Requirement Engineering
To determine the client’s needs
NOT what the client’s wants
9/17/2019

4. Requirements elicitation (capture)
The process of discovering the client’s requirements
Requirements analysis (understand and refine)
Once the initial set of requirements has been drawn up, the process of refining and extending them
9/17/2019

5. Elicitation & analysis flowchart
9/17/2019

6. Gain an understanding of the application domain
The specific environment in which the target product is to operate
Build a business model
Model the client’s business processes
Concept exploration (determine the client’s)
initial requirements
constrains (deadline, reliability, cost)
Iterate the above steps
Examples: banking, automobile, manufacturing, or nuclear physics, education
9/17/2019

7. Understanding the Domain (Before contact your client)
Every member of the development team must become fully familiar with the application domain
Correct terminology is essential
Construct a glossary
A list of technical words used in the domain, and their meanings
9/17/2019

8. Building Business Model (contact your client)
A business model is
a description of the business processes of an organization
The purpose is
for developers to further understand the clients
business so they can better advise clients
regarding to what they need
9/17/2019

9. A simple business processes of a bank
Accepting deposits and account withdraw
Loaning money to clients
Making investments
9/17/2019

10. Sources of requirements
Customers
Users
Administrators
Maintenance staff
Partners
Domain experts
Industry analysts
Information about competitors
Good requirements start with good sources. Finding those high-quality sources is an important task and, fortunately, one that takes few resources.
The primary sources of requirements are the Stakeholders, so begin by identifying them from among these candidates:
Customers
Users
Administrators
Maintenance staff
Partners
Ask each stakeholder to identify other stakeholders. By “peeling the onion” in this manner you can quickly identify all stakeholders so that you don't miss important perspectives and associated requirements.  This will help you identify and resolve conflicting requirements as early as possible.
These are other possible sources of ideas for requirements:
Domain experts
Industry analysts
Information about competitors
The last item often includes information about the current system that competitors are using to solve the business problem.
9/17/2019

11. Techniques Brainstorming Interviewing A questionnaire
Examination of business forms
Direct observation
Prototyping
Requirement gathering workshop
9/17/2019

12. The six key question types
What?
Why?
When?
How?
Where?
Who?
“I keep six honest serving men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.”
...Rudyard Kipling.
Ask the right questions!
9/17/2019

13. How requirements questions
How will you use this feature?
Is this feature a process and, if so, what are the steps? Or, what questions can I ask to ascertain the steps?
How might we meet this business need?
How might we think about this feature a bit differently?
How will we know this is complete?
9/17/2019

14. Where requirements questions?
Where does the process start?
Where would the user access this feature?
Where would the user be located physically when using this feature?
Where would the results be visible?
9/17/2019

15. When requirements questions?
When will this feature be used?
When do you need to know about…?
When will the feature fail?
When will we be ready to start?
9/17/2019

16. Who requirements questions?
Who will use this feature?
Who will deliver the inputs for the feature?
Who will receive the outputs of the feature?
Who will learn about the results of someone using this feature?
Who can I ask to learn more about this?
9/17/2019

17. What requirements questions?
What do I know about this feature?
Or, what assumptions am I making about this feature that I need to confirm?
What does this feature need to do?
What is the end result of doing this?
What are the pieces of this feature?
What needs to happen next?
What must happen before?
What if….? Think of all the alternative scenarios and ask questions about what should happen if those scenarios are true.
What needs to be tracked?
9/17/2019

18. Why requirements questions?
Why questions are great wrap-up questions as they help confirm that the requirements you just elicited map back to a need you identified when you scoped the project.
Is there any other way to accomplish this?
Does this feature meet the business need and solve the problem we’re trying to solve?
9/17/2019

19. Initial Requirements (contact your client)
The initial requirements are based on the initial business model
Vague, unreasonable, contradictory, impossible to achieve
Then they are refined
The requirements are dynamic
9/17/2019

20. Two categories of requirements
A functional requirement specifies an action that the software product must be able to perform
A nonfunctional requirement specifies properties of the software product itself
Platform constraints
Response times
Reliability
Functional requirements are handled as part of the requirements and analysis
Some nonfunctional requirements have to wait until the design workflow
9/17/2019

21. Develop SMART requirements
Make sure the requirement is:
Specific –clearly states what is required
Measurable – to confirm when it has been met
Achievable – can be done, eg. technically possible
Realistic – is reasonable, eg. cost is not prohibitive
Timely – achievable within an acceptable timeframe.
9/17/2019

22. SMART Definition – Specific:
Specific requirements are precise and:
Are not open to interpretation; and
Avoid absolutes (ex. – “all”, “never”, “always”).
9/17/2019

23. SMART Definition – Specific:
The document will contain all customer information:
Which document?
What customer information?
What format(s)?
The Declaration document shall contain this customer information in a text block in the top right corner of the first page: Customer Name, Phone,
9/17/2019

24. SMART Definition – Measurable:
Measurable requirements can be verified as complete and:
Avoid undefined time periods / quantities; and,
Avoid non-fact based measurements such as “best” or “optimal”.
9/17/2019

25. SMART Definition – Measurable
The application shall function quickly for end users:
How quickly (seconds, minutes, hours)?
Which application features are included?
Which users are affected – guests, administrators, everyone?
The application shall have response times of 4.00 seconds or less for all features, and for all user roles, during business hours of 9 AM – 5 PM ET, Mondays – Fridays.
9/17/2019

26. SMART Definition – Attainable
Attainable requirements are able to be achieved given the existing environment and are:
Appropriate for project / limitations; and,
Realistic to achieve within project parameters.
9/17/2019

27. SMART Definition – Attainable
The monthly cycle will be run on the last Friday of the month, between 7 PM and 8 PM ET:
Has this been verified to be possible?
What if the cycle runs longer than 1 hour?
The monthly cycle will be run on the last Saturday of the month, starting at 7 AM and completing by 7 PM ET.
9/17/2019

28. SMART Definition – Realistic:
Specific requirements are relevant and:
Are appropriate in context with other requirements; and,
Consider other related project constraints.
9/17/2019

29. SMART Definition – Realistic:
The new website will generate over 1,000,000 hits within its first 12 hours of implementation:
Is this likely / necessary to occur?
Is there a better way to measure this outcome?
The new website shall be ranked within the first results page on three (3) major search engines (Google, Bing and Yahoo) within its first 12 hours of implementation.
9/17/2019

30. SMART Definition – Time-Bound:
Time-Bound requirements are timely and:
Clarify how quickly a requirement needs to be finished, executed or implemented.
Avoid vague time references such as “fast”, “quick” or “soon”.
9/17/2019

31. SMART Definition – Time-Bound:
System availability will be achieved soon after the cycle is completed:
How soon (seconds, minutes, hours)?
What if the cycle is late?
System availability shall be achieved after cycle completion and by no later than 6 AM ET on Mondays – Fridays.
9/17/2019

32. Software Metrics
9/17/2019

33. 9/17/2019

34. Metrics for requirement engineering
Requirements changing frequency during the elicitation and analysis phase
Management use this to determine the rate of converging to the real requirements
# of requirement changes during the rest of the development process
Management use this to evaluate the techniques used during the elicitation and analysis phase
9/17/2019

35. Challenges
9/17/2019

36. 9/17/2019

37. “ I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant.”
S. I. Hayakawa ( ),
U.S. senator from California
9/17/2019

38. George Romney (1907-1995), U.S. presidential candidate
“I didn’t say that I didn’t say it. I said that I didn’t say I said it. I want to make that very clear.”
9/17/2019

39. Challenges in requirement engineering
What system analysts say is not what the client should be saying:
Clients don’t know what they need
Client can’t convey what they need
Client don’t appreciate what is really going on
It is easy to misunderstand what the client says.
Ambiguous of language
Complexity of software
9/17/2019

40. Object-oriented & classical path
9/17/2019

41. Gain Domain Knowledge Build Business Model Use Cases
Initial Requirement
Refine Use Case
& Requirement
Requirement Analysis
Build Rapid Prototype
Experiment with
Rapid Prototype
9/17/2019

42. Use Case Model
Models an interaction between the software and users of software (actors)
An actor is a member of the world outside the software product
An actor is frequently a user of the software product
A user of the system can play more than one role
Conversely, one actor can be a participant in multiple use cases
9/17/2019

43. An Example of Use Case Diagram
9/17/2019

44. Use Case Description for Check Out
Brief description:
The Check Out Book use case enables a borrower to check out a book with the aid of a librarian.
Step-by-step description:
0. The borrower hands the book and his or her card to the librarian.
1. The librarian enters C at the computer terminal, and then scans the bar code on the book and on the borrower’s card.
2. If the book has a hold on it for another borrower, the librarian does not allow the borrower to check that book out.
3. If the book has a hold on it for that borrower, the system clears the hold and then updates the relevant book data.
4. If there was no hold on the book, the system updates the relevant book data.
Unless there was a hold on the book for another borrower, the librarian stamps the book and hands it to the borrower.
The librarian returns the card to the borrower.
9/17/2019

45. CASE Tools Graphical tools for UML diagrams Object-oriented CASE tools
To make it easy to change UML diagrams
The documentation is stored in the tool and therefore is always available
Object-oriented CASE tools
Rational Rose (
Together
ArgoUML (open source) (
9/17/2019