Let me restate my definition of what that is. Requirements Management is the science and art of gathering and managing user, business, technical, functional requirements, and process requirements within a product development project. The project could be for a new consumer product, a web site, a system or a software application. In all these cases, the five classes of requirements should be represented.
The objective of the Requirements Management activity is to define a process whereby requirements for Enterprise Architecture are identified, stored, and fed into and out of the relevant Enterprise Architecture development phases. As such it forms part of the activities and steps carried out in each of these phases though it is not referred to implicitly in any projects I have managed.
(Requirements Management is also a discipline for both Quality Management (ISO 90001:2000) and Project Management (PMI)).
Target architecture must be based on credible assumptions about future business requirements. Getting these future requirements is not a simple matter of asking business management for them, and analyzing them is not the linear technique used to develop the design for a project. Instead, we have to use a combination of requirements aggregation and scenarios to gather and analyze long-term requirements. This will lead to more credible architectures with appropriate flexibility and evident business value.
For ease of use, it is convenient to think of requirements as belonging to a type.
They are the fundamental or essential subject matter of the service or product. They describe what the service or product has to do or what processing actions it is to take.
Business Cases or Scenarios should be used as a useful technique to discover and document these requirements.
Project and Portfolio Management (PPM) addresses the decisions regarding what projects to undertake, with what priority, and in what sequence. Before a project has gone through the necessary requirements definition activities, its scope is based on high-level requirements derived from business drivers, plans, and needs. If these requirements are viewed in isolation, then solutions will be defined in isolation, and they will ignore synergies or dependencies between projects and undervalue foundational projects that provide capabilities that can be leveraged across future projects. Business Requirements also have to be a source for Project Management methodologies.
They are the properties that the functions must have, such as performance and usability. These requirements are as important as the functional requirements for the product/service’s success.
These are restrictions on projects due to the budget or the time available to build a product or service.They impose restrictions on how the product/service must be designed. For example, it might have to be implemented in the hand-held device being given to major customers, or it might have to use the existing servers and desktop computers, or any other hardware, software, or business practice.
These are the business-related forces. For example, the purpose of the project is a project driver, as are all of the stakeholders-each for different reasons.
They define the conditions under which the project will be done. The reason for including them as part of the requirements is to present a coherent picture of all factors that contribute to the success or failure of the project and to illustrate how managers can use requirements as input when managing a project.
It is recommended to start testing requirements as soon as we start writing them.
We make a requirement testable by adding its fit criterion. This fit criterion measures the requirement, making it possible to determine whether a given solution fits the requirement. If a fit criterion cannot be found for a requirement, then the requirement is either ambiguous or poorly understood. All requirements can be measured, and all should carry a fit criterion.
Requirements Management and Enterprise Architecture cannot be dissociated.
Some vendors have perfectly understood the need of integrating this, such as Telelogic and the need to share a common metadata repository.
With that solution, there are possibilities to go from requirements, to enterprise architecture, to systems implementation and design, with tightly-coupled, bi-directional integration between DOORS (their requirements management tool), and Systems Architect.
IBM has it’s own requirements management solution but has (not yet) an enterprise architecture solution. This may change with the on-going acquisition of Telelogic, but I haven’t been really able to understand IBM’s strategy yet. Is this only a question of absorbing another market or a willingness to offer a full Enterprise Architecture suite in the Rational catalogue? (Requisitepro being obviously an issue….).
The HP approach seems to be the how to integrate the different application coming from the former Mercury and Peregrine world. HP PPM (and HP Quality Center for testing requirements). Their current approach is to use the Demand management module in PPM to manage business requirement at business level and using the module in Quality Center to specify the requirements at technical level to translate them in test case. Nevertheless, HP does not have any Enterprise Architecture solution.
5 comments:
All these areas are important, but the one area that tends to fall through the cracks seems to be non-functional requirements.
These generally translate map to key architectural design decisions that affect technical service level capabilities and "fit for service" characteristics in ITIL parlance.
These types of requirements are the most difficult for the business user to understand and the easiest for the business to overlook.
I generally explain the difference between functional and non-functional requirements with the example of a button on a form.
Functional requirements are concerned with what happens when you push the button.
Non-functional requirements are concerned with questions like how many times a button will be pushed a minute by how many users, how quickly mus the button repond when pushed, how you authenticate button users, when must the button be available and so forth.
This tends to help frame the discussion of these types of requirements in terms the business user can understand.
This is an excellent article.Lou that was an excellent response as well. I'm going to send it to my colleagues.Our company has been running very smoothly thanks to PM software. We are using software from Communiclique and are very happy with the effects it is having on our organization.
This is a very good article especially for organizations that are still trying to figure out a solution to its PPM, RM, and EA. We are currently looking at HP because so far we think it has the best solution for our PPM need. But still figuring out how well it can address our RM and EA.
Thanks for this article.
When organizations (or specific projects) are starting out in software development, they are open to the possibility of co-developing requirements and architecture. However, as people specialize in requirements management, they tend to view requirements as a driver for architecture. The reality is that requirements and architecture influence each other and if requirements are developed with architectural input, they may exhibit qualities of being too abstract or not being in tune with technology. As an example, requirements may assume a "page by page" display of information whereas Ajax allows for related information to be available readily.
First of all thanks for a great article. It outlines the issues faced in most of the projects that we have been involved in during the years.
We have developed a 100% web-based platform (ReqMan) for gathering and organizing requirements for Software Requirement Specifications.
The platform allows you to easily define the above structure and save it as a template for future use. You can also invite all stakeholders to suggest requirements and have the requirement specialists / technical writers review the suggestions and add them to SRS.
Best of all the platform is completely free and there is no catch. The platform is used globally from 1 person projects to some of the largest IT companies in the world.
Post a Comment