1. Managing Change and Quality
Sriram Mohan

2. Outline Managing Requirements Assessing Requirements Quality
It is generally not possible to create a definitive set of requirements for a system once and only once. We can create the perfect requirement specifications document and freeze them for the duration of the development effort and then declare everything past that point to be the responsibility of the maintenance team. A requirements management process can be useful only if it recognizes and addresses the issue of change.

3. Factors for Change External Internal
Unofficial sources contributed up to half of the total scope of the project
External factors are those change agents over which the project team has little or no control. Now matter how we manage them, we must prepare ourselves to be able to address change. These include things like changes in the market, economy, government regulations, technological changes. Users change their mind or perceptions about what they want. For example a user who was responsible for requirements could leave and the new user has a different idea of what needs to be done. Environmental change creates new constraints or new opportunities. The new system is ready to go, the existence of the new system creates a “yes but” syndrome effect and causes the requirements for the new system to change. The way people function with a new system will be different causing different things to be managed and new requirements.
Internal factors can also contribute to change. Failing to talk to the right stakeholders. Lack of a process to help manage changes to requirements that normally happen on an incremental basis. Typically requirements and design happen together, design might expose new requirements and to ignore them would be really foolish.
Enhancements mentioned by the distributors who had been overhead by programmers, direct customer requests to programmers, knee jerk change of scope reactions to competitors, functionality inserted by programmers thinking they would be useful to customers and finally easter eggs.

4. Managing Change: Primary Questions
How do you capture change requests?
How do you respond to these (individually & overall)?
How does this tie-in with tracing requirements?

5. A Process for Managing Change
The team must accept that change in inevitable and must plan for it. Have a way for capturing all change requests. If it comes from a stakeholder then it must be captured.
Step 1: Recognize that change is inevitable, and plan for it

6. A Process for Managing Change
Step 2: Baseline the requirements
This means they are signed-off on, and
From then on, they fall under change control – see below
Step 3: Establish a single channel to control change
No ad hoc additions
No ad hoc fixes, either
The team should baseline the requirements for each iteration. This will provide a way to distinguish between old requirements and new change requests. One can compare the new request to the old baseline to see if there is any conflict and whether it can be accommodated. This has to be done in an orderly manner and the customer shouldn’t get the feeling that they are being stonewalled. At the same time, one shouldn’t accept all the changes.
Ad hoc changes can cause significant scope creep. The customers wish for a change cannot be assumed to officially change the schedule and the budget and they have to be renegotiated. It is crucial to have a single channel through which change requests are submitted and accepted.

7. A Process for Managing Change
In  this big picture, you especially need to know what “release management”  is!
A CCB(change control board) must exist to manage changes. When a change request comes through, the CCB must consider the following factors
What is the impact of the change on the cost and functionality of the system
Impact of the changes on the customers and other stakeholders
Potential for the change to destabilize the system.
The fact that people want to make changes to a system is not a bad thing, the problem is when changes are not documented and analyzed before approving them. A simple change can cascade changes to other requirements and can leak to other life cycle stages. The problem here is really bad when change requests are made directly to a programmer who then start making changes in the code without capturing the change request and without worrying about the impact of the change on the rest of the requirements, design etc. A programmer does not have the authority to make a change to the feature list. This is where having an efficient traceability mechanism will be real useful.
Step 4: Use a Change Control System to Capture Changes Step 5: Manage Change Hierarchically
Figure on middle right from

8. Follow the link
There is a dependency between the various artifacts involved in requirements mgmt
Follow the chain and make sure that the change is propagated
Maintain a change history for every use case/requirement/ every project document and the entire project.

9. Outline Managing Requirements Assessing Requirements Quality
Quality has different interpretations depending on the situation, for instance, once can say quality is conformance to requirements or quality is achieved when the software is good enough. Quality is simply not about meeting the user needs and expectations, it includes the process that led to it, the measure and criteria that were used to demonstrate quality.

10. Products vs. Processes
Organizations that produce high-quality products invest in high-quality processes.
Product quality can be measured through testing.
How can we measure process quality?

11. Review Methods Informal Formal Active
Ask a peer to read and give comments
Formal
Ask a peer to prepare for review
Record and report results of review
Active
Interrogate reviewer

12. Checklists Look for anticipated defects
Some defects apply to almost all artifacts
Does the artifact exist?
Some defects are artifact-specific
Have you identified all stakeholders?

13. Problem Statement Checklist
Has a problem statement been drafted?
Is it written in an easy-to-understand way?
Does the team understand it?
Has it been circulated for agreement to the key stakeholders, including management?
Do the team members have agreement that this is the problem they are trying to solve?

14. Supplementary Specification Checklist (1/2)
Have you established an appropriate template?
Are all non-functional requirements included in the supplementary specification?
Have requirements for usability, reliability, performance and supportability been captured?

15. Supplementary Specification Checklist (2/2)
Have design constraints been identified?
Have supplementary requirements been linked to use cases where appropriate?