Requirements Management Remarks
Quote from Martin Fowler
“Models are neither good nor bad, they are simply more or less useful.”
DFH Note: Without documented requirements, how can a project be deemed unsuccessful (or successful).
Requirements Management = Risk Management
From a business perspective, requirements answer the “what” (not how).
Requirements management efforts can help in structuring a system from an object-oriented or class-based standpoint.
Four phases of requirements management
Discovery
Discovery – The learning process
Techniques for discovery are determined by: organizational culture, project type, other factors.
Techniques for discovery (ordered from least to most effective): Mining, Investigation, Collaboration, imersion.

Mining
(Least effective)
You’re given a stack of documents that others have produced – you have to go through and find all the requirements. Least effective because you have to interpret what the requirements are. You don’t know what you don’t know.

Investigation
Talk with people alone or in small groups . Down side: if you miss stakeholders, you miss requirements.
If groups have conflicting requirements, there can be trouble because groups with more power usually get what they want more often that groups with little power.

Collaboration
Similar to investigation but you get ALL stakeholders together at one time. This is a good technique for new products and major revisions.

Conversation
Use Index cards; don’t waste time; don’t get too detailed (keeps low investment in ideas on cards);
Different colors of index cards represents different concepts.
Note: used terms for the concepts that are “meaning neutral” to avoid associating with a bad connotation on the part of the stakeholders. Example: you might have one color card for “use cases”. Stakeholders have a bad idea of use cases due to negative prior experience. This leads to negative view of present concept.
Business Goals
(Blue)
Evaluate all other goals as to how they align to these business goals. Business goals help in framing the scope of the project.
Actors
(Green)
People and other entities that have interaction with the product or system.
Assumptions
(Red)
Statements made that you don’t know for certain to be factual. You don’t know it but you assume it.
System Processes
(White)
Functionality, use cases, features, user story, etc.
System Subjects (optional)
(Yellow)
purely business people may not need to participate in this part of the conversation. The system subjects cross over into the design – The “how”; includes entities, objects, classes… object oriented modeling.
Deliverable for the conversation session: “Conceptual View” document. This constitutes the transitions from requirements discovery into documentation.
This is the process of “memorializing” the results of the conversation. In this document you create a narrative of the process flow.
Follow Up
One-on-one sessions.

Immersion
The most effective technique for requirements discovery.
Cannot be used every time.
The idea is to “live” in the environment for a while.

Documentation
Our firm uses MS Word and Rational Requisite Pro (a requirements management tool)
With Requisite Pro, attributes can be assigned to requirements.
Delivery of requirements to programming team can be incremental as they emerge.
The requirements are written down in MS Word.
Key Point: The requirements should be stated at an atomic level, that is, they should NOT be open to interpretation.
If they are open to interpretation, they are less useful.
This creates the need for requirements that are very “wordy” – that’s OK.
Story boards are a good way of depicting system processes – Visio is a good tool for this.

Communication
This means translating the language of the stakeholders (Marketing, Sales, Accounting, etc.) into the language of software development.
This is often underestimated in terms of its importance.
Requirements are “micro-projects”. They have their own lifecycle.
A Requirements management tool allows attributes to be associated with the requirements.
Examples of requirement attributes:
Type of Requirement
Example values: Business rule.
Status
Example values: Proposed, Approved, In Development, In Testing, Passed, Failed, Pending Customer Validation (this one is a good way t get “customer signoff” when they wouldn’t do it otherwise).
Notes
Example values: Whatever.
Scheduled Iteration
This provides a way of managing risks.
History
Requisite Pro can keep an audit trail of requirements but it is hard to use; History attribute allows it to be manipulated like other attributes.
Requisite Pro allows filtered views to be exported to Excel and delivered to team members.

Verification
Also known as QA. Often gets left out. Ron’s opinion: Organizations often neglect this step because they don’t think it’s important or don’t want to spend the money/resources to do it.
Testing is based on requirements precisely.
In this model, QA is not tasked with identifying defects that are not directly associated with requirements. QA should not introduce new requirements.
Types of testing:
a. Unit testing
b. Integration / functional testing
Verify that the functional requirements are satisfied
Our firm uses “Rapid Requirements Gathering”.
Start with a vision then move to a requirements perspective.
Insist that all stakeholders are present at the requirements meeting.
End users tend to be focused on their personal interaction with the software and less on the overall goals.
Identifying stakeholders is NOT a requirements gathering activity.
The larger the group of stakeholders, the longer the requirements meeting takes.
It is not the role of the software development team to resolve conflicts between stakeholders.