Previous column

Next column

Creating a Project-Specific Requirements Engineering Process

Donald Firesmith, Software Engineering Institute, U.S.A.


space COLUMN

PDF Icon
PDF Version


In this column, I use a common situation facing many requirements engineers to illustrate that “one size does not fit all” when it comes to selecting a project-specific requirements engineering process. I then recommend a metaprocess for constructing such a process based on the use of a preexisting process framework and its associated repository of reusable process components. I conclude the column with a brief discussion of some of the benefits and risks associated with this approach.


Imagine that you work for a small to midsize company that develops software-intensive systems. Today, your company is essentially ad hoc when it comes to process. Each project and team within the project is responsible for determining how they are going to perform their tasks. However because of recent problems with quality and the failure of important projects to come in on schedule and within cost, management has recognized the need for more rigor when it comes to the system/software engineering process. Perhaps there is even some pressure from customers or members of management to achieve a specific score on a recognized process assessment such as the SEI’s Capability Maturity Model Integration (CMMI®; or ISO Spice ISO/IEC TR 15504 (

And now a new project is about to start. You have read a couple of requirements engineering books and maybe taken a one-day tutorial at some conference so you are perceived as the local requirements expert. Thus, you have been tasked to lead the requirements effort. And you have also been tasked to develop and document the project’s process for performing requirements engineering (RE), with the understanding that what you come up with is intended to become your company’s standard RE process if it works reasonably well on your project. So what do you do?
A fair number of you reading this column have probably either found yourself in this situation or else know of someone who has. Or maybe you are working for a similar company and suspect that someone will face this challenge shortly. What do you do?

You could write a brief memo stating that your RE process is the process described in your favorite requirements book. But this isn’t a very good solution because the book describes a general RE process, and you need one that is appropriate for your specific project. Also, even within your company, projects vary greatly in terms of their size, complexity, business criticality, technical difficulty, and this list of relevant factors could go on and on. You need an RE process that is both flexible enough for multiple projects but yet is also appropriate for your specific project. Also, you cannot expect all of the stakeholders and participants in the RE process to take several days off from their busy schedules to read an entire book. And finally, the book describes lots of tasks, techniques, and work products, several of which will probably not be appropriate for your specific project.

You could try to write a longer and more detailed document describing exactly which parts of the book are relevant, how you are tailoring other parts of the book, and how you are extending the book with ideas you’ve taken from other books and the conference tutorial you took. But basically, the result would be too complex and confusing to be practical. And besides, management wants you to produce a well-documented company-specific RE process or set of processes. They want to see real standards, procedures, guidelines, and templates.

Another possibility would be for you to hire a consultant experienced in both process and RE. Such a consultant could either develop a RE process for you or work with you to develop the process. The need for the RE process to be project-specific and appropriate and feasible within your corporate culture would require the consultant to work closely with you. Unfortunately, hiring the consultant to help you develop the process from scratch is not practical because there is insufficient funding to hire someone who is adequately qualified for the amount of time that would be required. You need someone with practical industry experience, and the only person you can afford for the necessary time is a professor at the local university who doesn’t have that practical experience. For schedule and budget reasons, you really need to do most of the work yourself, limiting the use of the consultant to possibly a small amount of initial guidance followed by the later review of the mostly finished RE process.

What you really need is for someone experienced to have already done most of the work for you. You need access to a set of consistent RE process components (task descriptions, technique descriptions, templates, guidelines, etc.) that you can reuse. You also need them to be relatively inexpensive (or better yet free) because you cannot afford to buy sufficient licenses for a tool that would provide a user friendly access to the reusable RE process components. You could spend lots of time on the Web searching for individual reusable RE process components, but you would have to deal with the fact that they were not designed to work together as part of a single process framework and may therefore be inconsistent. Actually, you need the equivalent of a class library of reusable RE process components that you can pick and choose from. You need a RE process framework [ALC2000] with an associated repository of reusable RE process components.


Once you have decided to create a project-specific RE process using a repository of reusable RE process components, you need to determine a reasonable metaprocess (i.e., process for processes) for using it to produce your project-specific RE process. I recommend the following basic metaprocess that you should feel free to modify to fit the specific needs of your organization. Although this metaprocess is written in a roughly temporal order, it is typically performed in an iterative, incremental, parallel, and time-boxed manner until an acceptable project-specific RE process is obtained.

  1. Determine Your RE Process Needs. Determine the types of projects that your RE process framework will have to support. The wider the range of projects, the larger and more complete the repository of reusable RE process components must be as well as the more tailorable and user-friendly the individual RE process components must be. You should consider the following factors when determining your RE process needs:
    • Size and Complexity. In terms of the size and complexity, what is the range of the associated systems to be produced? This will determine the size of the projects in terms of staffing, funding, and schedule. Large complex projects need larger and more formal RE processes than small simple ones.
    • Contractual Issues. Will the projects involve subcontracting or partnering? The requirements for such applications may well be part of a contract and thus be legally binding. Such projects also tend to have more separation between customers, users, developers and even partners, subcontractors, and vendors. Thus, the requirements for such projects need to be more formal and of higher quality.
    • Legal and Regulatory Issues. You may be required to use RE processes that are compatible with various international and governmental standards. These may be ISO standards (e.g., ISO/IEC 12207;, IEEE standards (e.g., IEEE STD 830-1998; military standards, security standards (e.g., FIPS PUB 140-2;, and safety standards (e.g., MIL-STD-882D; The process repository will then need to include the required process components, and these components must be compatible in content and meaning with the requirements of the standards.
    • Support for Assessment. You may be required to use RE processes that will enable you to achieve a specific level on some major process assessment scale such as the SEI CMM ( or ISO Spice ( The RE process repository will then need to include the required process components.
    • Distributed Development. When the project is distributed geographically, the specification and communication of the requirements will need to be more formal and better documented. Whether you use email or you will have good requirements tools to enable multiple distributed teams to simultaneously and collaboratively work on the requirements, you still have to deal with time differences.
    • Business Criticality. Some projects are very business critical with the success or failure of the project having a major impact on the success or failure of the business. Other projects may involve the development of simple throwaway prototypes. The more critical the system is to the business, the more critical it is that RE is successful and the more formal its process will tend to be.
    • Requirements Volatility. The more volatile the requirements, the more important it becomes for the requirements process to support the quick and easy modification and addition of requirements. The requirements process must be agile, although that does not necessarily mean that the requirements process needs to be superficial.
    • Stakeholder Involvement. The more involved that the stakeholders (e.g., user representatives, management, subject matter experts, architects, testers, assessors, and regulators) are in the RE process, the more important that they both understand the RE process, that they can perform their allocated tasks in the process, and that they can understand the resulting work products.
    • Process Breadth. Do you need a process framework that is restricted to RE, or do you need a general process framework that covers all activities (e.g., from management, development, operation, and retirement), whereby RE is only part of the framework? In order to ensure cross-activity consistency, RE is best performed within the context of the entire system or software engineering process. Selecting a general purpose process framework and repository can avoid unnecessary duplication of work and “turf battles” that may occur between RE and other related activities.
    • Corporate Culture. Any RE process must be acceptable to (and usable by) the staff that must use it. Personnel performing RE must have the minimum level of training and experience to perform the tasks, use the techniques, and produce the work products of the process. Similarly, they must feel comfortable with the level of formality and completeness of the process. This in turn will influence the way and the level of detail to which the process is documented. The staff must see the process as either helpful or necessary, or else they will not use it.
    • Tool Compatibility. Do you already have a set of existing Computer-Aided Software Engineering (CASE) tools with which the process must be compatible (e.g., produce the same work products)? Although the process needs should drive the selection of the process and the selection of the process should drive the selection of the associated CASE and other tools, often tool vendors successfully (and unfortunately) sell their products as solutions to your process needs before organizations have yet determined their process needs.
    • Metrics. Has your management determined that you need to collect specific types of RE metrics (e.g., requirements completeness, requirements volatility, and requirements quality)? Sometimes, the type of metrics required can influence the process because the process must create the data on which the metrics are based.
    • Budget. You may have been given a budget (in terms of staff, funding, and calendar time) in which to develop and incorporate the RE process. Given a limited budget, you may have no choice but to select a process that is less complete than you would like (and need).

    The preceding subbullets influence the size, completeness, and formality of the needed RE process, which in turn influences the size and completeness of the process framework and its associated repository of reusable process components that you will select and obtain in the next step. This determination can be made manually, and it can also be supported by an automated "process consultant" tool such as the OPF Process Consultant (

  2. Identify and Obtain the Process Framework. Once you understand your RE process needs, you can identify and obtain (buy or acquire access to) the repository of reusable RE process components you will use to produce your project-specific RE process. There are several repositories of reusable process components available that incorporate RE components (e.g., RUP, OPF and Ralph Young Some RE process frameworks and repositories are being rapidly maintained and updated whereas others are relatively static. Some are supported and augmented by many consultants and books, whereas others are restricted to “what you see is what you get.” Some are general purpose repositories of reusable process components (e.g., RUP and OPF), whereas others are restricted to RE (e.g., Ralph Young’s process components).
    • Size and Completeness. Some repositories of reusable process components are very large and complete, supporting the entire system/software engineering process including development and operation. Other repositories are quite small and of restricted scope. Large and complete repositories have the advantage of almost always having the process component you need so you do not have to extend the repository yourself, which can be very difficult and expensive, especially in the middle of a project. They also allow you to develop consistent processes for all major development and operational activities. However, it may be much easier to identify the relevant process components in a small focused repository unless the larger repository is well organized and supplied with a powerful search capability.
    • Cost. Some repositories of reusable process components are free (e.g., OPF and Ralph Young), whereas some must be purchased from a vendor (e.g., RUP). The purchase price can vary considerably and may be out of reach of many smaller companies and projects. Also, the cost of any necessary training and consulting should also be factored in.
    • Tailorability. Some are open source (e.g., OPF) and thus highly tailorable whereas others have little or no tailorability (e.g., Ralph Young).

  3. Learn the Process Framework. If you are playing the combined roles of requirements engineer and process engineer, you need to learn the basics of the process framework you have chosen. You need to learn its metamodel ( of process component types (e.g., RE work products, tasks, roles, teams, techniques, and conventions) and be able to quickly understand and identify those RE process components most likely to be relevant to your specific project. This will include both the relevant RE process components as well as possibly those process components from other disciplines such as management (scope control), configuration management (of requirements and requirements documents), quality assurance (e.g., technical evaluation and review of the requirements and requirements specifications), risk management (of requirements related risks), etc.
  4. Select the Relevant RE Process Components. The first actual step in constructing the project-specific requirements engineering process is selecting the relevant RE process components from the repository of reusable process components that you will use to build it. Except for the RE tools (including the requirements repository and any reusable requirements), the stored process components are essentially informational; they are descriptions of the requirements work products (a.k.a., artifacts), languages, work units, producers, conventions, etc. that will make up the process.
    • Select the Requirements Work Products. First select the formal requirements work products that will be delivered to the customer organization and then select the informal intermediate work products that will be used to develop the formal work products. These include requirements, requirements models, and various types of requirements specifications. These may also include application vision statements as well as various types of analyses such as customer, user, and technology analyses.
    • Select the Requirements Languages. Select the relevant natural, modeling (e.g., UML, and formal (e.g., Z or object-Z requirements languages used to build the requirements work products.
    • Select the Requirements Work Units. Once you have selected the requirements work products, you can select the specific tasks and techniques to be used to generate them. Relevant tasks might include customer analysis, user analysis, technology analysis, visioning, requirements identification, requirements analysis, requirements specification, and requirements management. Relevant techniques might include (but are not limited to) brainstorming, elicitation, interviews, questionnaires, storyboarding, task analysis, use case analysis, hazard analysis, prototyping, iterative development, incremental development, joint application development, and cross functional teams.
    • Select the Requirements Producers. Select the producers (i.e., people, roles they play, teams, organizations, and tools) that will perform the selected work units to produce the selected requirements work products. These might include the requirements team, the requirements evaluation team, the various roles played by members of these teams (especially requirements engineer), and the various requirements tools (e.g., requirements modeling and requirements management) that they will use. Allocate the requirements work units and work products to the requirements producers that will perform and produce them.
    • Select the Requirements Stages. If not already selected, then select the development/life cycle as well as its relevant phases, builds, and milestones during which RE will be performed. Allocate the performance of the requirements work units and development of the requirements work products to their associated stages of development, especially the milestones by which the requirements work products must achieve a specific level of completion and approval.
  5. Tailor the Selected RE Process Components. Merely selecting the reusable process components will not make the resulting RE process adequately project-specific. For example, it is not enough to decide to produce a system requirements specification (SRS); you must also decide how complete the specification must be in terms of its contents. Similarly, deciding to have a requirements team is insufficient; you also have to decide what the makeup of the team should be in terms of roles. Likewise, tasks can be performed using many different techniques and produce varying amounts and types of work products. Reusable process components often are very complete because it is easier to tailor out unnecessary subcomponents than it is to add missing subcomponents, especially at the beginning of the project when the requirements team should be concentrating on engineering requirements instead of trying to decide how to engineer requirements. Thus, tailoring most often involves deleting subcomponents of the process components that are inappropriate or not cost-effective. Tailoring may also involve making changes to existing subcomponents, such as assigning a task to a different role than the default one chosen by the developers of the repository. This will involve tailoring the task out of the description of the default role and adding the task to the description of the new role. Thus during this step, you both tailor out existing subcomponents and make modifications to remaining subcomponents.
    Note that depending on the amount and difficulty of tailoring that is required, this may well be the most time-consuming and costly individual step in this metaprocess to develop a project-specific RE process.
  6. Extend the Reusable Repository and Process Framework. No matter how complete a process framework and associated repository of reusable process components might be, there is always the possibility that it needs to be extended with additional process component types and associated process components that were not envisioned or completed by the supplier of the repository of reusable process components. Extension may mean the addition of new process components (e.g., that provide new tasks for a more complete RE activity, new requirements work products, new roles, etc.). It may also require the addition of new subcomponents to existing components (e.g., the addition of new techniques to an existing task or the addition of new sections to existing documents).
  7. Document the RE Process Components. Except for reusable requirements and RE tools, the reusable RE process components are essentially documents that describe the tasks, techniques, roles, work products, conventions, etc. that make up RE. The documents should be written it in a form that is appropriate for their varied readership of stakeholders in the RE process. However, the form that they exist in the requirements repository may or may not be appropriate. For example, the reusable process component documents may be Microsoft Word documents, Adobe Acrobat PDF documents, HTML files, XML files, or even paper documents. These documents may therefore need to be translated into the appropriate form for use on the project. This redocumentation may involve change of media (e.g., paper to electronic), change of file type (e.g., MS Word to XML), and the addition of organizational branding (e.g., adding brand logo and using brand colors). This is especially a problem if the modifications and extensions are derived from sources outside of the repository or if the repository contains components in different formats or media.
  8. Integrate the RE Process Components. It is not sufficient to build (i.e., reuse, tailor, extend, and document) the individual RE process components. You must also integrate them into a consistent RE process that conforms to the associated process framework’s metamodel. For example, if the reusable RE process components (i.e., process descriptions) contain hyperlinks to other process components, then the preceding tailoring, extension, and documentation steps may have broken some of the existing links and created “orphan” components. Another issue is whether or not the selection, tailoring, extension and documentation steps are performed manually or are supported by a repository-specific process engineering tool. If performed manually, there is a high probability of integration problems (e.g., broken hyperlinks); if performed by a process engineering tool, then there should be few if any integration problems.
  9. Verify the RE Process Documentation. The integrated RE process should be verified to be complete, consistent, and usable, especially if the tailoring, extension, documentation, and integration were performed manually.
    • Complete. The integrated RE process should contain all selected RE process components. The required documentation for a reusable process component should also include all required topics. For example, the standard contents for the documentation of a requirements work product may include name, purpose, intended audience, intended uses, content, and guidelines. Similarly, the standard documentation for a requirements task may include name, purpose, steps, techniques, inputs and outputs, and guidelines.
    • Consistent. The integrated RE process components should be consistent with each other. There should be referential integrity, in the sense that if the documentation of one RE component mentions another (e.g., if a role performs a task and a task produces a work product, then the role produces the same work product). The documentation of a process component in the integrated RE process should not refer to another process component that is not in the integrated RE process.
      Note that the difficulty in maintaining and verifying referential integrity is one reason why the reusable RE process components in some repositories do not mention other RE process components (or at least minimize the number of references or hyperlinks). Unfortunately, this lack of references makes it more difficult to browse the RE process and determine the exact meaning of the process components.
    • Usable. The integrated process should be usable by its intended audience of stakeholders. This could include such quality attributes as readability, navigability, and search capability.
  10. Validate the RE Process. Once the integrated RE process has been verified for basic completeness, consistency, and usability and any identified defects have been fixed, you should have it validated by its stakeholders for appropriateness (e.g., adequacy, appropriateness, formality, and agility) to the project in terms of project size and complexity; contractual, legal and regulatory issues; support for assessment and distributed development; requirements volatility; stakeholder involvement; corporate culture, tool comparability, metrics, and budget.
  11. Approve and Publish the RE Process. Once the integrated RE process had been verified and validated, it can be approved by management, published as the official project RE process, and made available to its stakeholders for actual usage on the project. Publication may take the form of actual production and distribution of one or more paper documents (e.g., plans, standards, procedures, and guidelines) or hosting on a project-internal website.
  12. Train the RE Process Stakeholders. Successful use of a new RE process by stakeholders who are either unfamiliar with it or with the RE discipline will typically require process-specific training. Training will typically consist of some initial classroom training followed by on-the-job training within and by the requirements team.
  13. Use the RE Process. The proof of any process is in its use. As the project-specific RE process is actually used on the project, members of the requirements team and other stakeholders will be able to determine what parts of the process work and what parts require improvement.
  14. Iterate the Process. Depending on the existence and quality of the process engineering tool support and the amount of bureaucracy existing in the approval and publication step, you may be able to rapidly and easily iterate the RE process in an on-going fashion, update the RE process at specific milestones, or update the RE process at the end of the project. What ever the case, the RE process should be considered to be living documentation that is developed and maintained in an iterative manner as lessons are learned.



By creating a project-specific RE process by reusing a standard repository of consistent process components, you can expect to obtain the following benefits:

  • Increased Product Quality. Many defects are introduced during requirements engineering, and these defects tend to have a disproportionate negative impact on the project. By using a better RE process, the project can minimize these defects and decrease the associated risk to the project.
  • Increased Process Quality. Preexisting process components have been developed by professional methodologists and experts in requirements engineering. They are more likely to be of much better quality that process components developed under the project’s schedule pressures by staff requirements engineers who have less experience, both in requirements engineering and in process development.
  • Improved Productivity and Schedule. By not having to develop the RE process from scratch, the requirements team can develop the process much faster, allowing them to concentrate on using it rather than building it. These time savings allows the requirements team to develop more expertise in the application domain.
  • Consistency and Compatibility. Whereas the project’s requirements engineering team can create a project-specific process, they are also reusing process components that can also be used to develop requirements engineering processes for other projects within the organization. Such consistency can help with training costs and the ability to move staff from one project to another. If they are from a repository of general purpose process components, the reused RE process components were also developed to be consistent with other processes on the project, such as management (scope control), configuration management (of requirements and requirements documents), quality assurance (technical evaluation and review of the requirements), risk management (of requirements related risks), etc.
  • Process Assessment. The use of a well-documented, industry-best-practices requirements engineering process can help the organization achieve a better score on a standard process assessment such as CMM and ISO Spice.


Whereas many of the preceding benefits of reusing a standard collection of consistent process components can decrease the overall project costs, there are also costs associated with using such an approach:

  • Acquisition Costs. Most repositories of reusable process components (e.g., RUP) must be purchased from a vendor, and only a few (e.g., OPF) are available for free. Although the acquisition costs are considerably less than what it would cost to develop the repository from scratch, the purchase price is none-the-less significant, especially if:
    • You must purchase multiple seats or an organizational and site license.
    • You must purchase the entire process repository including the entire range of process components, many of which may not be relevant.
  • Construction Costs. It takes time to identify and select the appropriate process components and build the project-specific process out of them. The process framework may or may not come with tools to help you select components and construct the new process, possibly as a (consistent set of) paper document(s) or a hyperlinked informational website.
  • Tailoring and Extension Costs. It takes time to tailor the reused process components to fit the needs of the specific project, and extend the repository with missing process components. These costs also depend on how easy it is to find and select the relevant process components and how tailorable the individual process components are (e.g., in terms of deleting unnecessary subcomponents and modifying remaining subcomponents). It also depends on how easy it is to create new and yet compatible components.
  • Verification Costs. It takes time to verify the project-specific process for completeness, consistency (e.g., the proper removal of unnecessary subcomponents without the introduction of dangling references and orphaned objects), and usability.
  • Consulting Costs. The typical requirements engineer does not have adequate experience in requirements engineering, being either an engineer who has been tasked with requirements engineering or a full-time requirements engineer who has been too busy with his or her head in the trenches to keep up with the latest developments in requirements engineering. The typical requirements engineer may also not have adequate experience in process engineering. Thus, the requirements engineer may need consulting support, either internal or external, from professionals in both requirements engineering and process engineering.
  • Training Costs. Even with a well-documented RE process, there will be training costs (classes, books, and staff time) required to teach all of the stakeholders in the new process once it is developed. Because the process is project-specific, some of the training should be specific to the new process.

However, one must weigh these costs against the significant costs due to requirements defects that may result from reusing a general purpose requirements engineering process or from attempting to develop a project-specific process from scratch. Given the criticality of requirements engineering, I strongly recommend considering the approach identified in this column.


Even when reusing a standard repository of consistent process components, there remain significant risks:

  • Lack of Tailorability. Not every repository of reusable process components has associated tools that make their components easy to tailor. Often, the process components have to be manually tailored, and this requires the components to be open source or to specifically include tailoring in the contract.
  • Ease of Tailorability. Tailoring tools need to be flexible and easy to use. If tailoring is to be done manually, then the form of the process component needs to support tailoring; thus the components should be written in simple and well formatted text (e.g., MS Word .doc files), HTML, XML, or Java. Process components documented in PDF files will require access to an Adobe Acrobat writer as well as the free Acrobat reader.
  • Appropriateness. After all the work of producing a project-specific RE process, there is still the possibility that the end result may still not be appropriate if it does not take into account all of the relevant factors (e.g., size, complexity, criticality, staffing, culture, contracts, etc.) and all significant stakeholders. If a consultant is used, care must be taken that the consultant does not push his or her favorite standard process if that does not meet the specific needs of the project.
  • Usability. The resulting process components should be easy to use by their intended audience of stakeholders. Descriptions should be easy to read, and work-product templates should be easy to instantiate. It should also be easy to navigate around the many components to find the desired components. The framework of components should also be based on a clean and intuitive metamodel of process component types.

When performing a risk analysis of this recommended approach, one must also take into account the far greater risks associated with reusing a general purpose RE process or with attempting to develop a project-specific process from scratch. Given the criticality of requirements engineering, I strongly recommend considering the approach identified in this column.


As this column has demonstrated, it is not trivial to produce a project-specific RE process. There are definite costs and risks that the benefits must outweigh. However, given the criticality of requirements engineering, the development of a project-specific RE process is usually the optimal approach. The primary question is how to do produce one. Should you:

  • Reuse a general purpose RE process as documented in some requirements engineering book or set of standards.
  • Develop a project-specific RE process from scratch.
  • Instantiate a project-specific RE process by reusing preexisting process components from one of the available repositories of such components.

As a separate observation, the astute reader has probably guessed that there is little if anything about the recommended metaprocess for developing a project-specific RE process that is in fact specific to requirements engineering. Every other discipline on the project is subject to the same needs and challenges, and the same metaprocess will work for them (assuming that the repository is large enough and not restricted to requirements engineering). In fact, that is one of the benefits from the approach recommended in this column. If everyone on the project uses the same approach and the same repository of consistent reusable process components based on the same metamodel and framework, then they will be more likely to produce an overall project-specific development process that minimizes the unnecessary overlaps and inconsistencies that often plague the boundaries between disciplines.


[ALC2000] Alcázar, Enrique Garcia and Monzón, Antonio, “A Process Framework for Requirements Analysis and Specification”, in the proceedings of the 4th IEEE International Conference on Requirements Engineering (ICRE’00) held 19-23 June 2000 in Schaumberg, Illinois, IEEE, pp. 27.



The views and conclusions contained in this column are solely those of the author and should not be interpreted as representing official policies, either expressed or implied, of the Software Engineering Institute, Carnegie Mellon University, the U.S. Air Force, the U.S. Department of Defense, or the U.S. Government.


About the author

space Donald Firesmith is a senior member of the technical staff at the Software Engineering Institute (SEI). He has worked exclusively with object technology since 1984 and has written 5 books on the subject. He is currently writing a book on the engineering of safety, security, and survivability requirements. Most recently, he has developed a 1,100+ page informational website on the OPEN Process Framework at He can be reached at

Cite this column as follows: Donald G. Firesmith: “Creating a Project-Specific Requirements Engineering Process”, in Journal of Object Technology, vol. 3, no. 5, May-June 2004, pp. 31-44.

Previous column

Next column