The ISO standard is related to the definition and requirements of a quality management system. It helps an organization to operate with increased effectiveness, consistency and customer satisfaction and have the capability to continually improve the management system.
ISO 9001:2000 is based on eight Quality Management Principles which are comprehensive and fundamental rules of belief, for leading and operating an organization, aimed at continually improving performance over the long term, by focusing on customers, while addressing the needs of all stakeholders.
Principle 4 is referring to a “Process Approach”. The standard promotes the adoption of a process approach when developing, implementing and improving the effectiveness of the quality management system. A desired result is achieved more efficiently when activities and related resources are managed as a process.
Product realization is a system of processes by which inputs, such as raw materials or components from suppliers, are transformed through the activities of the organization, such as value added production or assembly operations, into outputs, such as products or components, which meet the needs and requirements of a customer.
Any activity or operation that receives inputs and converts them into outputs can be considered as a process. Almost all activities and operations involved in making a product or providing a service are processes.
When an Enterprise Architecture Committee receives suggestions for strategic changes, they should immediately translate those changes into changes in specific business processes. If the architecture is well-defined, changes in processes will immediately suggest changes in specific applications and databases. There are many definitions of a Business Architecture but they all refer to the definition of processes.
The business architecture is a formal documentation of the lines of business, their support functions and their relationship to each other. After the architecture has been documented, it is systematically analyzed to examine the functions (services) required by business and to align the enterprise technology with those functions.
Companies which have already documented their business architecture (baseline/as-is) may consider to have achieved a great step getting the ISO 9001:2000 certification.
Showing posts with label ISO 9000. Show all posts
Showing posts with label ISO 9000. Show all posts
03 December, 2007
Requirements Management and Enterprise Architecture
I was describing a while ago the relations between Requirements Management and other types of user’s demands.
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 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.
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.
Subscribe to:
Comments (Atom)
