Student Notes: Requirements Elicitation Reloaded

This is a follow up to my previous write-up on Requirements Engineering.

Gurkan Yeniceri maintains his COMP 8100 : Software Requirements Elicitation and Analysis documents at this wiki.

He discusses the rationale for the use of a wiki here. COMP8100 is a core component of the Master of Software Engineering program at the Australian National University.

Gurkan’s notes are a must read for any interested student!
Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.

Requirements Churn

Often software development begins with a concept, an idea, a mere verbalization of an intangible. This is followed by a concerted effort to nail down the requirements for the proposed system.

Requirements are seen as a formal necessity for flagging off the development effort.

Usually, a formal requirements statement is approved for conversion into design. In many instances, where the problem domain is novel or fast-paced, the software effort runs into hurdles due to either late-breaking or rapidly-changing requirements. Or the requirements might evolve blazingly fast due to timeline pressures.

This is requirements churn.

The causes for the high rate of change of requirements pose a serious problem to the maintainability of the development effort. It becomes increasingly difficult to ensure that the code base is in sync with the requirements and design models (the boundaries between these two often becoming blurred). This is greatly exacerbated by traditionally elaborative software development processes which posit many implicit implementation assumptions during the coding effort — assumptions which are neither documented in the design nor in the requirements. This is not due to a lack of trying on the developers’ part. In the world of vastly complex enterprise software development, sourcing changes back to the design and requirements models may sometimes entail a substantial investment of effort and resources.

Project documentation and maintenance is not child’s play.

With translational and model driven development, the compiled executable system is deemed an immutable. Changes are mandated to be sourced to the requirements and design models. This ensures that the rationale for design and implementation decisions is captured as information and knowledge, and helps avoid the anachronistic mis-step between requirements and implementation.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.

Student Notes: Requirements Elicitation

Requirements Elicitation
Class Notes

Chemboli Srinivas

May 2005

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
Wiegers' template?

* 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
interface requirement.

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:

* Context

* Environment

* Who works

* Priority

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

* Objectives

* Operational policies

* Constraints

4. Background

* Operational environment

* Interfaces

5. Quality Attributes

6. What support exists?

7. Defining the need

* Why the need?

* Prioritizing needs

* Constraints and assmptions

Next Lecture

* Asking questions for the hotel requirements.

* Probably has special requirements.

17 March 2005

Business Risks

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

Use Cases

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.

Rules (General)

1. When not to have a meeting

2. Schedule with respect to out of office work, etc.

3. Presentation preferences (should SMM track where
people are?)

User Interface

1. Simple to use

2. Do not nest menus too deep!

How to Proceed

1. Start identifying business requirements for SMM,
missing stuff

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.

Next Week


Questions on the SMM

1. Current problems to be solved by the proposed

2. Learning system?

3. Security roles: authentication, card charge,

4. Accountability

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?

* Hardware

* Software

9. Personal meetings, work, out of work?

* Prioritization

* 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

3. Redundancy?

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
arranging meetings

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.


* meeting

* rules

Out of Scope:

* active switching

* meeting management

* tracking

* integration

In groups, identify:

* Business requirements

* Business rules

* formulate a couple of use–case (event action lists).
Define actors and use cases.

Business Requirements

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
of SMM.

Functional Requirements

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
organizational structures)

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?