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.
http://sergethorn.blogspot.com/2007/12/requirements-management-and-enterprise.html
No comments:
Post a Comment