Requirements are the beginning and the end of any IT projects. Not properly managed requirements can sink a project. I like the brief introduction of Requirements Management from Wikipedia:
Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform.
I like it because it not only described the processes requirements are involved in, but also about “controlling change and communicating to relevant stakeholders”. I will elaborate more on that later.
The initial set of requirements from customers, are usually in the highest form, such as “I want to have user subscriptions and monthly newsletter sent to these subscribers”. We will refer here as Business Requirements (BR). The Project Manager and Architect will have to break them down into further details and verified with the customers. Following the previous example, the finer form will be “user subscriptions” and “monthly newsletter sent to subscribers”. Let us name these as Detail Requirements (DR). These can be broken down further (if so desired). Regardless of any style of development process, it is always the best policy to break a requirement into its atomic requirements.
Hence the system we are building should handle both the BR, and respective DR. The relationship is 1 BR is to 1 or more DR.
Requirements can also arise from issues or enhancements. Issues (ISU) resulting in changes in the end product should be recorded as requirements (RISU) as well. The recorded requirements must be able to link back to the issues that prompted them. The relationship is 1 ISU to 1 or more RISU, and possibly 1 RISU to 1 or more ISU.
The next step is to get approval by the customers or stakeholders. Stakeholders may include your own company’s internal stakeholders. For example your Chief Architect might want to ensure the products or solutions are inline of the your company’s policy. Besides handling the who, system must also provide the how and when of requirements approval.
The requirement management system should allow the stakeholders to put in comments besides plainly accept or reject a requirement. The sequence of stakeholders to seek approvals from must also aligned with the stakeholders’ roles and responsibilities. Therefore an approval workflow is needed for the requirement management system. Of course, this workflow must be configurable to suit different business process.
In conclusion, I shall use the Use Case diagram to represent all the above mentioned.
And also an ER diagram to show the possible relationships between the different forms of requirements.