Software Requirements - Part 5

This is the fifth and the last part of the following book summary.



Previous posts:

• Software Requirements - Part 1
• Software Requirements - Part 2
• Software Requirements - Part 3
• Software Requirements - Part 4

Software Requirements Management

Requirements management includes all activities that maintain the integrity, accuracy, and currency of the requirements agreement as the project progresses.

No one approach is universally correct because projects differ in their flexibility or features, staff, budget, schedule and quality. Base your choice on the priorities that the key stakeholders establish during project planning.

The requirements baseline is the set of functional and nonfunctional requirements that the development team has committed to implement in a specific release. The base-lined SRS document should contain only those requirements that are planned for a specific release. Requirements baselines are dynamic. The set of requirements planned for a specific release will change as new requirements are added and existing ones are deleted or deferred to a later release.

Your organization should define the activities that project teams are expected to perform to manage their requirements. Documenting these activities and training practitioners in their effective application enables the members of the organization to perform them consistently and effectively. Your process descriptions should also identify the team role that's responsible for performing each task. The project's requirements analyst typically has the lead responsibility for requirements management.

Every team member must be able to access the current version of the requirements, and changes must be clearly documented and communicated to everyone affected. Consider appending a version number to each individual requirement label, which you can increment whenever the requirement is modified.

A more sophisticated technique stores the requirement documents in a version control tool, such as those used for controlling source code though check-in and check-out procedures.

The most robust approach to version control is to store the requirements in the database of a commercial requirements management tool.

You can find detailed feature comparisons of these and many other tools in International Council on System Engineering web site.

The main benefits of a requirements management tool are:

• Manage versions and changes
• Store requirements attributes
• Facilitate impact analysis
• Track requirements status
• Control access
• Communicate with stakeholders
• Reuse requirements

These products show a trend toward increasing integration with other tools used in application development.

Think of each requirement as an object with properties that distinguish it from other requirement. A rich set of attributes is especially important on large, complex projects but selecting too many requirements attributes can overwhelm a team such that they never supply all attribute values for all requirements and don't use the attribute information effectively.

Software developers are sometimes overly optimistic when they report how much of a task is complete. They often give themselves credit for activities they've started but haven't entirely finished. Track status against the expectation of what "complete" means for this product iteration.

Measuring actual development and project management effort requires a culture change, and the individual discipline to record daily work activities. Effort tracking isn't as time-consuming as people fear. The team will gain valuable insights from knowing how it has actually devoted its effort to various project tasks. Note that work effort is not the same as elapsed calendar time.

What about Requirement Changes?

Most developers have encountered an apparently simple change that turned out to be far more complicated than expected. Such uncontrolled change is a common source of project chaos, schedule slips and quality problems.

An organization that is serious about managing its software projects must ensure that:

• Proposed requirements changes are carefully evaluated before being committed to.
• The appropriate individuals make informed business decisions about requested changes.
• Approved changes are communicated to all affected participants.
• The project incorporates requirements changes in a consistent fashion.

The closer you get to the release date, the more you should resist changing that release because the consequences of making changes become more severe.

Using short development cycles to release a system incrementally provides frequent opportunities for adjustments when requirements are highly uncertain or rapidly changing.

The Change Control Process

The change control board has been identified as a best practice for software development. The CCB is the body of people, be it one individual or a diverse group, who decides which proposed requirement changes and newly suggested features to accept for inclusion in the product. A higher-level CCB has authority to approve changes that have a greater impact on the project.

Policies are meaningful only if they are realistic, add value and are enforced.

Useful change-control policy:

• All requirements changes shall follow the process
• No design or implementation work other than feasibility exploration shall be performed on unapproved changes.
• The contents of the change database shall be visible to all project stakeholders
• Impact analysis shall be performed for every change.
• The rationale behind every approval or rejection of a change request shall be recorded

Many teams use commercial problem or issue-tracking tools to collect, store, and manager requirements changes. Remember however that a tool is not a substitute for a process.

The CCB Chair will typically ask a knowledgeable developer to perform the impact analysis for a specific change proposal.

Impact analysis has three aspects:

• Understand the possible implications of making the change.
• Identify all the files, models, and documents that might have to be modified if the team incorporates the requested change.
• Identify the tasks required to implement the change, and estimate the effort needed to complete those tasks

Skipping impact analysis doesn't change the size of the task. It just turns the size into a surprise. Software surprises are rarely good news.

It is useful to create a checklist to help you in the process. The book contains lot of examples.

Many estimation problems arise because the estimator doesn't think of all the work required to complete an activity. For substantial changes, use a small team - not just one developer - to do the analysis and effort estimation to avoid overlooking important tasks.

To improve your ability to estimate the impacts of future changes, compare the actual effort needed to implement each change with the estimated effort. Understand the reasons for any differences, and modify the impact estimation checklists and worksheet accordingly.

Requirements Tracing

It's hard to find all the system components that might be affected by a requirement modification.

Traceability links can help you build a more complete picture of how the pieces of your system fit together. On many projects you can gain 80% of the desired traceability benefits for perhaps 20% of the potential effort.

Defining traceability links is not much work if you collect the information as development proceeds but it's tedious and expensive to do on a completed system.

Determine the roles and individuals who should supply each type of traceability information for your project. Educate the team about the concepts and importance of requirements tracing.

It's impossible to perform requirements tracing manually for any but very small applications. Requirements tracing however can't be fully automated because the knowledge of the links originates in the development team members' minds. However, once you've identified the links, tools can help you manage the vast quantity of traceability information.

If you're maintaining a legacy system, the odds are good that you don't have traceability data available, but there's no time like the present to begin accumulating this useful information.

Even if your products won't cause loss to life or limb if they fail, you should take requirements tracing seriously.

Don't define traceability links until the requirements stabilize. 

The Impact of Software Requirements

The path to improved performance is paved with false starts, resistance from those who are affected, and the frustration of having too little time to handle current tasks, let alone improvement programs.

Requirements lie at the heart of every well-run software project, supporting the other technical and management activities.

It is interesting to consider the relationship of requirements to other project process.

It's not surprising that the long-suffering people at the end of the requirements chain, such as technical writers and testers, are often enthusiastic supporters of improved requirements engineering practices.

If customer-support costs aren't linked to the development process, the development team might not be motivated to change how they work because they don't suffer the consequences of poor product quality.

Process changes don't always result in fabulous, immediate benefits for every individual involved. A better question - and one that any process improvement leader must be able to answer convincingly - is , "What's in it for us?" Every process change should offer the prospect of clear benefits to the project team, the development organization, the company, the customer, or the universe.

Conclusion

The single biggest threat to a software process improvement program is lack of management commitment. Professional software practitioners don't need permission from their managers to better themselves and their teams. However, a broad process improvement effort can succeed only if management is motivated to commit resources, set expectations, and hold team members accountable for their contributions to the change initiative.

Keep the following four principles of software process improvement in mind:

• Process improvement should be evolutionary, continuous and cyclical.
• People and organizations change only when they have an incentive to do so.
• Process changes should be goal-oriented.
• Treat your improvement activities as mini projects.

Even motivated and receptive teams have a limited capacity to absorb change, so don't place too many new expectations on a project team at once. Write a roll-out plan that defines how you'll distribute the new methods and materials to the project team and provide sufficient training and assistance.

Accept the reality of the learning curve - that is, the productivity drop that takes place as practitioners take time to assimilate new ways of working. This is part of the investment your organization is making in process improvement. 

Software project managers must identify and control their project risks, beginning with requirements-related risks. Formal risk management planning is a key element of a successful large-scale project. Project managers can control requirements risks only through collaboration with customers or their representatives. Jointly documenting requirements risks and planning mitigation actions reinforces the customer-development partnership.

Nothing is more important to a software project's success than understanding what problems need to be solved. If you actively apply known good practices and rely on common sense, you can significantly improve how you handle your project's requirements, with all the advantages and benefits that brings.