Student Notes: Requirements Elicitation

April 21, 2006 § 1 Comment

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
system.

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
wait.

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
manipulated.

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

SRS

Questions on the SMM

1. Current problems to be solved by the proposed
system?

2. Learning system?

3. Security roles: authentication, card charge,
malware?

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
meetings

3. Redundancy?

4. Which hierarchies of projects or meetings to be
supported?

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.

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.
Legislation).

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
devices)

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
attract?

In this case, Business Rules will be too hard to get?

Advertisements

§ One Response to Student Notes: Requirements Elicitation

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

What’s this?

You are currently reading Student Notes: Requirements Elicitation at csrins.

meta

%d bloggers like this: