Student Notes: Requirements Elicitation
April 21, 2006 § 1 Comment
10 March 2005
* Using standards for requirements (e.g. MIL 498)
* Getting the scope of the system.
Just having a document is not enough.
Ask questions–what sort in context to fill out
* Early on, requirements can cover
* Business requirements
* Use case scenarios
* Business rules (customer might have them)
* Constraints (Design, etc.)
But there is other information also:
* Solution ideas (thinking about how things might work.
But do not go too specific in implementation.
When collecting requirements, e.g. HCI is an internal
External interface requirements can be how the system
interacts with other system, and not how user interacts.
Wiegers only talks about external interface requirements.
The OCD: Operational Concept Document
What it is: Describes the proposed system.
VSD: Vision and Scope Document
This is similar to the charter in project management.
Karl Wiegers provides a template.
The intent of the VSD is the same as the OCD:
* to get consensus from stakeholders
* business needs
The VSD also describes a proposed system:
* Who works
But remember, a VSD only scopes a system, not the needs.
Drawback of a vision statement: Can get carried away
with too much detail.
Scope and limitations can also define the release structure.
Business rules append to the VSD:
1. how they operate in the new environment with the new
2. what rules can and cannot be supported.
Questions for the OCD
1. Mandate: how do we start?
* Is there a current system?
* What is the need? What led to the need? (Why?)
* People involved (stakeholders)
* What is the history?
2. What are the referenced documents?
* Existing procedural manuals
* Existing need surveys
3. Current system
* Do you have a current system?
* Describe the current system
* Benefits and disadvantages
* Operational policies
* Operational environment
5. Quality Attributes
6. What support exists?
7. Defining the need
* Why the need?
* Prioritizing needs
* Constraints and assmptions
* Asking questions for the hotel requirements.
* Probably has special requirements.
17 March 2005
1. Be aware of them
2. Constantly address them
3. Only focusing on technical aspects is a risk. There
are other risks in addition to technical risk.
4. Identify risks early on.
5. Investors are always interested in the break-even
point. And the returns should be warranted after the
The Vision and Scope document is the initial foray for requirements.
The Operational Concepts Document is overkill for
projects less than two man years or so. (Projects
taking about 6 months or so.)
But business needs must be proper for large projects.
Remember, size does matter.
After the VSD or OCD, use cases etc. are the
continuation of the communication with the customer.
Now, use cases are known as stakeholder cases.
Refer to Alistair Coburn's book: Advanced Use Case Modeling
1. Oriented towards system behavior
2. Describe how the system responds to a stakeholder
3. follows from a scenario
4. not focusing on internals, but on stakeholders who
are (usually) outside unless of course, they are
internal to the system.
5. Good for generating communication with stakeholder
However, do not go overboard with use cases!
Error handling should be considered in design. Do not
handle them in DFDs!
When dealing with use cases, it is beneficial to focus
initially on Actor, Description, Pre-conditions,
Post-conditions, and Normal flow. Use other
characteristics if useful, but don't get carried away!
Refer to the book: Requirements Engineering–Processes
and Techniques (Wiley)
Drawbacks of Use Cases
1. Not really useful in identifying the data that is
2. No indication of order of flow of operations.
Use cases can also be combined with Event Action Lists.
The general assumption–event stimulus is from outside,
but sometimes the system itself generates an event.
Usually time is involved.
A good rule of thumb:
* actions are verbs
* while events are the noun
Smart Meeting Manager
1. People on move
2. Constant information required
3. Can phone in, check PDA or can be buzzed too.
1. When not to have a meeting
2. Schedule with respect to out of office work, etc.
3. Presentation preferences (should SMM track where
1. Simple to use
2. Do not nest menus too deep!
How to Proceed
1. Start identifying business requirements for SMM,
2. Lot of stuff is missing
3. Then form the use cases
Finally produce: after the mid-term break:
1. OCD (Operational Concepts Document)
2. VSD (Vision and Scope Document)
3. Use cases
4. Event Action Lists
Today: Get the questions;
Next Week: Use Case discussion.
Questions on the SMM
1. Current problems to be solved by the proposed
2. Learning system?
3. Security roles: authentication, card charge,
5. Integration, interoperation with other systems (e.g.
project management systems)
6. Target users?
7. Who are the potential stakeholders?
8. What is the scope of the proposal?
9. Personal meetings, work, out of work?
* Exposure of information?
10. Projected schedules for this proposal?
11. Is it even feasible?
12. Which features first?
13. What when this trips up?
14. Breakeven point?
15. Costs to schedule a meeting?
24 March 2005
Discussing the Smart Meeting Manager
1. Scheduling virtual meetings?
2. Prioritization–flag some meetings to be absolutely
critical and cannot be in in conjuction with other
4. Which hierarchies of projects or meetings to be
5. Prioritization of roles? If a meeting is scheduled,
but the key person rollbacks?
6. Abort meeting?
7. Minutes of meetings?
8. Updates using a timestamp?
9. Scoping–keep management of actual meeting for
future enhancements, and concentrate more on
10. Escalation of priorities?
11. Scope out integration with other systems
12. Context of scheduling meeting
13. How much use? Safety?
14. Switching between devices?
15. Log-in and log-off
Ignore questions out of scope.
Out of Scope:
* active switching
* meeting management
In groups, identify:
* Business requirements
* Business rules
* formulate a couple of use–case (event action lists).
Define actors and use cases.
In context of the OCD and the VSD, are for SMM Pty Ltd.
What we need to get out of the system is for customers
Business rules may not be explicitly identified now,
but potential business rules may be identified (e.g.
VSD: Everything related to the project.
OCD: Scoped out and bound by rules.
Class discussion on the requirements
1. Automate scheduling of meetings
2. Facilitate reminders
3. Automate rescheduling of meetings
4. Roles in scheduling meetings (depending on
5. Heterogeneity (different interfaces for different
6. User's positional context
7. Reduce cost/time for scheduling a meeting
8. User initiation and training
9. We have X amount of money and so many resources
10. What is the Business Plan to break even?
All of these are more like Functional Requirements.
An example of a Business requirement: How are we going to
start this project and keep it afloat?
* Have at least a customer who is interested to go?
* Time to market?
* What is the minimu number of customers we can
In this case, Business Rules will be too hard to get?