Latest Updates: RM RSS
-
Peter
-
Peter
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 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.
I’ve added the following comment:
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…
I think that projects are too often managed inside-out and that the project is made responsible for managing the requirements of the system it must develop. Additional problem is that most system lifecycles are divided in different not very well connected stages like Business Case, Design, Build, Launch, Use & Maintenance and (the often overlooked) Disposal. A project itself starts often at the Design stage and ends with the Launch stage. So when a project is responsible for managing the system requirements it will focus on that stages only and use tools which match the technical nature of those stages.
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….
