Dimension: Requirements or Business Demands
(Note: This is part of the “Dimensions of SCM Challenge” series.)
Changing or unknown requirements can be a huge source of problems for a development team. Fortunately, configuration management is designed to support exactly this development problem. Books and tools abound that address the issues of managing changes, documenting and tracing requirements, and ensuring that the true needs of the eventual customers are met by the project. Requirements elicitation and elucidation, change management, and traceability tools are all available in the commercial market, and Agile development methods can ensure that customer representatives are involved from the very beginning. Tracking changes to requirements is not the same as tracking changes to software, but nearly every CM tool vendor offers an extension or plug-in for requirements management. Similarly, the requirements management tool vendors offer change tracking systems, as well as integrations with CM tools.
The most basic requirements challenge is knowing that a requirement exists at all. When a project transitions from a “clever idea” to a formal product, or switches from development to maintenance, the developer(s) will begin to get change requests and feature suggestions from a multitude of new sources. Keeping track of the ideas, and which ones are approved, is an important first step. Frequently this is implemented using the team’s change tracking tool. As the difference between requirements and change requests becomes more clear, the team can move to Formal Requirements Management.
The next source of requirements challenge is simple: a requirement to do something really, really hard. There isn’t much that CM can do to help directly with this kind of requirement. A good requirements management tool will, however, be able to predict the impact of the requirement—which parts of the project are affected by the requirement, and so likely to change. In some cases a single difficult requirement is really a Technical Complexity challenge (solve the Traveling Salesman problem), or a Technological Diversity challenge (integrate with a decades-old legacy system), rather than a requirements challenge. Please refer to the appropriate article, when they come out.
One common form of the “hard to do” problem is a requirement that the development team has never faced before. If a team that is accustomed to performance requirements is suddenly faced with a peak power requirement, for example, the team may get “stuck” with little or no idea of how to proceed. This may genuinely be a hard problem, but more likely is that the solution already exists. The solution in this case may be a new technology, especially if the requirement is being driven by managerial enthusiasm. Beware of hearing “this is the new state of the art” in meetings, and expect to deal with Technological Diversity challenges. When a team is facing an entirely new category of requirement, Subject Matter Expert is a good bet for a solution.
Another source of heretofore-unseen requirements is organizational change. When an organization is being divided, or when two organizations are being merged, some new and strange requirements can appear. (“Integrate our product with that other product over there. Make it seamless!”) Beware of other Organizational Structure challenges, obviously. Sending an envoy from one team to another makes sense as a basic Subject Matter Expert approach, but identifying someone to be sent to another team can also identify them as a target for layoffs—there aren’t a lot of easy answers.
When the challenge stems from the number of requirements, the complexity of the requirements, or from the need to verify the requirements, the answer is going to be Requirements Management. (It seems a little shady to be classifying an entire discipline as a CM technique, but this isn’t a requirements management journal.) CM tool vendors have a variety of requirements management solutions already available, and the biggest tool vendors—Rational (now IBM) and Telelogic (now IBM)—offer requirements management tools that integrate with their CM tools. (DOORS famously integrates with nearly everything.)
The last source of requirements challenges, and the most common, is frequency of change. When requirements changes (including new requirements) occur too fast, the development team can’t keep up. Symptoms include the reappearance of defects or deviations that have been fixed, excessive trouble testing the product, problem reports citing recently-updated requirements, and customer complaints about unresponsive or inadequate development. If the requirements change cycle is significantly faster than the development cycle, the list of pending changes can grow ridiculous. When this happens, development may respond by asking for an incredibly long requirements change and review cycle, typically tied to the development cycle. This is a symptom, and the solution is to speed up the release cycle, not slow down everything else. Consider an Agile development approach, in order to tighten up the feedback from development to customers.
The organizational techniques can be tremendously valuable when dealing with requirements challenges. A Change Control Board is an excellent source of detailed analysis when composed correctly. If you already have a CCB that you fear might be wrongly constructed, consider creating an additional one within the development group(s) with the right make-up. The ‘correct’ composition will depend on the type of requirements that are presenting the challenge. Functional requirements will need a functional CCB, procedural requirements need an organizational or managerial CCB. The benefit here is that each member of the board is looking at changes from the point of view of their own area of expertise. Parochialism is a benefit, since proposed requirements and proposed implementations can be checked in some detail.
System Architect does not offer the same diversity of interests that a CCB does. However, a single person with the entire system in his head provides a different value. The System Architect is going to have a strong grasp of how the different parts of the system interact. In combination with a construction technique like Component-based Development or Service-oriented Architecture, the architect can review and analyze a larger volume of system changes than a CCB. When rate of change is the primary source of challenge, System Architect is a good technique for dealing with technical requirements.
In fact, a System Architect is essentially a specialized Subject Matter Expert in the context of requirements challenges. While a System Architect offers quick, informed understanding of technical requirements changes, a Subject Matter Expert can be created or hired for any kind of requirements challenge. This makes Subject Matter Expert the organizational technique of choice for rate-of-change challenges. Unfortunately, it can take months for a SME to get up to speed on a technical project. The particular nuances of a long-standing project take time to learn. Obviously the actual time required will be different for each separate aspect of the project. A DBA may come along quickly for table & index performance issues, but then take months to comprehend all the triggers and stored procedures that are used. Keep in mind that Subject Matter Experts are not strictly technical. There are plenty of experts available for process, management, and business requirements. (This is a shameless plug: the author is one of those available experts!)
The codevelopment techniques are useful to address rate-of-flow challenges. Simultaneous Development is an obvious requisite. There are occasionally situations (usually involving a common file or table) where serialized development is put forward as a solution to rate-of-flow challenges. It is better to make a simple process change to deal with this—choose one official maintainer of the file or table in question and assign all changes to that item to the designated victim. You may have to create “child” requests or tasks for this, but it is simpler and more effective to give all the funny stuff to one expert.
Of the ceremonious techniques, Automated Enforcement of Standards and Gated Workflow can help with requirements challenges when they are used in conjunction with other techniques. The object with these techniques is to devise a process that will help with requirements challenges, and then automate it. Obviously, Automated Enforcement of Standards is a win if the standard is one of the requirements. But it can also be used to execute test cases, which ties in nicely with Fast Feedback on Changes. Similarly, Gated Workflow can be used to involve a SME or CCB in the process, requiring sign-off before changes enter development. Gated Workflow can also help ensure that regression testing or impact analysis are done after a change is delivered. Finally, Requirements Management is a strong technique to use with rate-of-flow challenges. If a requirement is just unfamiliar, or merely incredibly difficult to implement, then requirements management may not offer much benefit. When a large number of requirements are changing, or when they are constraining the response to a smaller set of changing requirements, Requirements Management is the way to go.
(This was published as part of “Dimensions of SCM Challenge #2: Standards and Interfaces & Requirements or Business Demands” in CM Journal, Vol. 6, No. 3, March 2008.)
March 17th, 2008 at 06:30 UTC
The most confusing part about requirements and requirements management is the unclear definition of the term “requirement”. Some people are saying everything that constraints a system is a requirement other do use smaller scopes, like stating that requirements only should be in the problem space or that requirements are the implementation of rules (whatever they mean by rules).
So how can you manage if it is not clear what you want or should manage?
Managing stuff like rules, principles, interests and requirements in order to make a success of projects is a social issue and not a technical one. If the stakeholders are not willing to pursue the same goals and don’t have empathy for each others concerns then no process, method or tool will help to solve the problem of the failing projects…
March 17th, 2008 at 06:57 UTC
Doing better » Dimension: Requirements or Business Demands
On the “Doing better” is an article posted about Dimension: Requirements or Business Demands:
Changing or unknown requirements can be a huge source of problems for a development team. Fortunately, configuration management is designed to su…
March 17th, 2008 at 12:59 UTC
Peter,
It has never occurred to me to think of understanding requirements as a challenge. I think in general that whenever I have seen requirements being managed, the team “just knew” what the requirements were and were not. Maybe that was because of good training, or because they hired a SME for the requirements gathering phase.
On the other hand, all those RQM tool vendors offer training, so it’s probably not totally intuitive. So how can we characterize the “amount” or “intensity” of the requirements challenge? Is it worse to not know what you want to manage, or if the stakeholders don’t agree on priority?
Are there other characteristics of requirements challenges? What about social identifiers?
March 17th, 2008 at 15:09 UTC
Austin,
For me the biggest requirements challenge is that the stakeholders should be responsible for managing their own requirements and they shouldn’t trust a temporarily project team to do it for them. A project team by nature will focus on the design and build stages of the system lifecycle and put other requirements important to the other lifecycle stages on a lower priority to meet their own deadlines. When a project team starts building there is too little time to keep managing new or changing requirements and redesign or rebuild stuff…
In theory most projects do have some external (outside the project) steering committee or governance body but in practice they most of the times do not take their responsibility but they do trust the project team fully as long as the team meets its deadlines. Stakeholders must and should be able to validate their requirements continuously and not only just before and after the design and building stages.
On my site I ended the post with the reference to this article with:
When do the stakeholders see that they must take responsibility to manage their own requirements during the total lifecycle of a system and they must do that from an outside-in view (looking to the system from its context)? And that if they need tools for requirements management it must be community-enabling social networking tools….
July 27th, 2008 at 03:38 UTC
[...] Tags: Governance, RM, Stakeholders On the “Doing better” is an article posted about Dimension: Requirements or Business Demands: Changing or unknown requirements can be a huge source of problems for a development team. [...]