Question

SUBJECT: INFORMATION TECHNOLOGY, CLASS: ADVANCE DATABASE MANAGEMENT

Hello Everyone,

I need help on a project for my ITD 256 Class. These are the questions I am suppose to answer:

Project: The project should include designing a database deals with making a proposal for the database implementation. You can either try to fix an existing problem in your business or create a new database for the new projects or new clients. Please define the objective, scope, and time frame of your project.

You should give a brief explanation of the problems or description of the new project. You should make suitable assumptions and add appropriate attributes wherever appropriate and then build an Entity-Relationship or Relational model of the database. The design must at least have five entities and generally it should not have more than ten.

The next step should implement the database tables from the normalized set of relations created in the previous step. Data should be suppplied for each table. The amout of data should be such that the need for a database is clear. In other words, provide enough examples to demonstrate why a database was required in the first place.

The SQL CREATE TABLE statements for the tables should include seperate ALTER TABLE ADD CONSTRAINT statements to add primary and foreign key constraints.

Provide SQL INSERT statements for adding the sample data to the tables.

INSTRUCTIONS:

1) A presentation, in your own words, of what the needs of the enterprise are.

2) A list of all assumptions.

3) A presentation of the strengths and weakness of the proposed solution.

4) The presentation should be between 10 to 15 minuites long.

5) Provide presentation slides, proposal, and SQL queries.

Answer 1

I tried this if it doesnt match your answer please comment

Definition: Requirements define the capabilities that a system must have (functional) or properties of that system (non-functional) that meet the users' needs to perform a specific set of tasks (within a defined scope).

Keywords: agile, elicitation, elicitation techniques, project scope, requirements, requirements attributes, requirements elicitation, root cause, scope, spiral, stakeholders, user requirements, users, waterfall

MITRE SE Roles and Expectations: MITRE systems engineers (SEs) are expected to be able to elicit business, mission, and operational needs from operational users and other stakeholders. They are also expected to be able to analyze, integrate, and transform these needs into system requirements as well as to facilitate stakeholder engagement on and resolution of requirements. MITRE (SEs) are expected to be able to tailor the principles of requirements elicitation to different development methodologies (waterfall, spiral, agile, etc.).

Overview

After operational needs are assessed and the concept of operations (CONOPS) and high-level concept definition are completed, the next step—and typically the first task on development projects—is to discover, elicit, collect, define, and analyze requirements. Requirements cover various aspects of a capability or system—user needs, behavioral, quality, implementation, etc. Given these, SEs will analyze, transform, and integrate users' needs into system requirements. For more information on the first steps in development projects, see the SEG's Concept Development topic.

Figure 1 highlights a typical process for collecting and evaluating requirements. Allocating sufficient time and effort to the requirements process to build a strong foundation for the effort has proven to be cost effective in the long run.

Requirements broadly covered Requirements details validated Requirements prioritized Requirements documented Revise detailed requirements Continue prioritizing & revise requirements as needed and/or modify, and delete Root Cause Analysis requirements No No Yes No Obtain Stake- Details clarified Discover & elicit high-level require- ments Stake- holders Stake- scope summary approval detailed require- Yes ments priorit ized? agree requirements are correct & complete, & customer approves stakehol concur? validated? require- SMEs and locate relevant Yes nts other resources Add, modify, delete, and track requirements and maintain documentation Incorporate changes Proposed changes Pre-launch Investigate options? Solutions? COTS? Cost-benefits? Prototypes? Yes Start requirements Yes process CONOPS Freeze requirements Were changes approved using change management process? Set up a format Launch Plan Implements usin waterfall, spiral, or agile model requirements changes in scope? process for changing requirements Yes Reiterate, go back Next step, forward Question, evaluate, decide Activities after requirements No No Review change Design, develop, test, etc. until project (or part 1 of a phased implementation) ends collection ends

igure 1: Overview of Requirements Collection and Change Processes (Click to enlarge)

Figure 1 shows activities and milestones that have long been part of the requirements collection and management processes. Each step within the requirements sequence is completed before moving on to the next step. Activities may be added, modified, deleted, and their sequences changed, depending on the scope and type of project or task. Generally, subtasks within a larger project focus on fewer activities and may have different stakeholders and finer grained criteria for success than the project itself.

Users provide functional and non-functional requirements, which form the substrate on which the project is built. Functional requirements are associated with the capability to directly support the users' accomplishment of their mission/tasks (features, components, etc.). Performance/functional requirements are those that are typically implicit and technical in nature that emerge as system requirements to satisfy non-specific needs (e.g., quality of service, availability, timeliness, and accuracy). SEs work closely with users to observe, discuss, and understand the users’ requirements and assess viable approaches to ensure they are met. It is generally accepted that, when possible, the practice of stabilizing requirements early in the project’s life cycle facilitates subsequent project work and significantly reduces risk.

When a project's outcome heavily depends on the success of the software component, lines between the project’s strategy and the software’s implementation methodology sometimes blur. The Software Development Life Cycle (SDLC) is a process methodology for software development. Models using SDLC are waterfall, spiral, and agile. The model selected depends on factors such as the project's size, complexity, aims, and objectives; the degree to which requirements are well understood and articulated up front; the stability of the environment in which the system will function; and, most important, the customer’s needs, availability during the project, and risk tolerance. A very important consideration is the project’s timeline.

• Waterfall model: Relatively low-risk projects use the waterfall model and progress through a series of phases/milestones in a linear fashion over time. The initial phase is often the requirements task. The first milestone occurs when the user and stakeholders have documented, validated, and approved a complete set of functional, performance, and other requirements. Phases that follow are design, implementation, testing, integration, operations, and maintenance. Each phase is formally documented, validated, and approved. Failure to meet a milestone may require repeating one or more of the preceding phases until deficiencies are corrected. The SE is expected to maintain the requirements document to reflect changes that may be made during these phases. This type of model is feasible when the customer mission or business is fairly static; the need is focused; the end user’s environment is stable; risks associated with cost, schedule, security, and other important factors are low; and significant changes in requirements during the project are highly unlikely. It is prudent to inform the customer during requirements collection, especially before final approval, that requirements’ changes in projects using the waterfall model can be costly.
• Spiral model: When starting a project without a complete set of documented requirements, the spiral model may be selected to reduce project risk incrementally as well as to deliver the requested capability more quickly. When requirements are partially known but the basic operational needs and concepts are well understood, the project can begin with the expectation that remaining requirements will evolve over time. Each cycle or iteration in the spiral model follows the same processes: define objectives, consider alternatives, recognize constraints, and generate a usable prototype. The initial loop starts with the CONOPS and life-cycle planning. Successive loops include high-level requirements, software requirements, preliminary design, detailed design, development, and test. The model works by building progressively more complete versions of the software working outwards. The SE collects and documents requirements at the start and updates them after each cycle. At the end of each cycle, stakeholders analyze risks and develop appropriate risk-reduction strategies for use at the next level. The customer evaluates the work and may suggest modifications for the next loop. The project can end at any point if the customer determines that the prototype satisfies the requirements and can be made operational.
• Agile model: The Agile Manifesto [1] states a preference for "working software over comprehensive documentation." In contrast to formal requirements documentation, agile requirements may be expressed in short non-technical statements called "stories." The agile model is used to develop a system over the course of successive 2–4 week iterations (i.e., sprints) using stories as planned inputs to sprints. Documenting requirements is part of the development process and focuses on what has actually been done. Agile documentation must meet three criteria, namely, that it be essential (have minimal detail), valuable (be needed), and timely (done just in time). Initially, small efforts are performed and requirements are focused on small, specific capabilities with the customers and developers teaming to work the interplay of requirements and capabilities together. Elements key to the success of agile projects are very short cycles, substantial customer collaboration from start to finish, close team work, open and constant communication among participants, adaptability on the part of all team members, and incremental development. The SE may wear several hats in an agile environment by providing support as needed, for example: identifying emerging requirements that may violate standards and regulations; analyzing, then documenting requirements as they evolve; calculating metrics; and writing functional specifications, test cases, meeting minutes, and progress reports.
• Using multiple models: More than one model can be used during a project's development. For example, a project built on the waterfall model may use the agile model for all or part of the software development phase, or milestones associated with the waterfall model are incorporated into the spiral model. Regardless of the particular model, all approaches should include requirements elicitation and some form of documentation. The activities in the Best Practices and Lessons Learned (below) are often associated with the waterfall model, but many can be modified for use with other models as well. SEs may change, reorder, repeat, or omit activities on the list, depending on the project type, complexity, methodology, and environment. A structured approach can help guide the requirements collection process from the first (i.e., "kick-off") meeting between SEs and stakeholders until requirements are baselined and approved. These guidelines are applicable and adaptable for requirements collection on large and small systems, new systems, and existing systems that are being updated or replaced. Requirements that evolve over time due to mission changes, business environment changes, etc. must be updated to stay current.

• Challenges exist today with the requirements engineering process. Frequently, sufficient time is not allocated to understand operational concepts and requirements associated with them; requirements are specified but not managed to accommodate changes; requirements are not revisited often enough to further assess trade-offs that users might consider in order to manage schedule and costs.

• Best Practices and Lessons Learned

  Apply good interpersonal skills. Such skills are always an asset, but they are a necessity when eliciting requirements. When SEs are objective and open-minded and have good listening skills, their relationships with users and other team members are productive. Their ability to effectively communicate project status and resolve issues and conflicts among stakeholders increases the likelihood of the project's success.

  Think broadly. SEs with broad knowledge of the enterprise in which requirements are being developed (whether for a system, service, or the enterprise) adds value and may be able to identify cost-effective solutions (e.g., process changes).

  Be prepared. Collect data and documents that provide context for the project. Review data generated during enterprise and concept analysis, and review any business case and decision briefings for the project. Become familiar with historical information, organizational policies, standards, and regulations that may affect requirements and impose constraints. Gather information on previous projects, successful or not, that share characteristics with the new project. Review their system specifications and other technical documents, if they exist. SEs may derive "explicit" or "implicit" lessons learned and requirements from data on the previous project. Find out whether there are descriptions of current operations, preferably an approved concept of operations (see the SEG's Concept Development topic), and any documented issues. Some of this material may identify potential stakeholder types and subject matter experts (SMEs) that may be needed. Draft a requirements collection plan, estimate resources needed, and consider the types of tools that would be appropriate on a project using this particular methodology. Identify potential risks that might arise during the requirements collection process (e.g., key stakeholders are unavailable due to time constraints) and plan risk mitigation strategies.

  Identify and manage stakeholders. A single individual or organization often initiates a project. Inevitably the new project will affect other individuals, organizations, and systems, either directly or indirectly, thereby expanding the list of stakeholders. Stakeholders' "roles" are the executive sponsor funding the project and possibly a contributor to requirements; primary stakeholders and others providing functional and performance requirements; stakeholders affected by the project indirectly (e.g., interfacing businesses and operations) who may contribute requirements; SMEs (e.g., managers, system architects and designers, security staff, and technical and financial experts); and stakeholders who must be kept in the loop (e.g., business analysts, legal and financial experts). As needed, stakeholders should be asked to review, comment on, and approve requirements for which they are responsible. Set up a process for communicating with stakeholders (e.g., meetings of all types, formal presentations, bi-weekly reports, and email).

  Determine the root cause of the problem. Before requirements collection starts, it is critical that the SE answer the question: What is the real need that the project and its product are intended to address? The SE must tread carefully but resolutely in the user's environment to uncover the real vs. perceived needs. Examining some of the concept and operational needs information can help with the analysis. The next vital question is: Have all stakeholders agreed on a clear and unambiguous need statement that is consistent with the business case? The SE's ability to state the problem in an implementation-independent manner is extremely important. Customers may find it difficult to accept the fact that their solution to their perceived problem is not viable or that other options should be explored.

  Define the capability scope. The SE generates the capability scope that provides a framework for the project and guides the requirements collection process. The capability scope is usually the first source of information about the project available to all stakeholders before the project gets under way. Stakeholders review it and customers approve it. The SE's goal is to elicit and discover all requirements and ensure that each is within the boundaries described in the scope. This criterion is used to evaluate requirements' changes throughout the life cycle. Scope assessments are not limited to the requirements phase. They are often used to cover project activities from launch to completion, specific activities (e.g., pilots and testing), and for small tasks within larger projects. Capability scopes are generated as needed, for example: before or after requirements collection, or for inclusion in a request for proposal, work breakdown structure, or statement of work. Other documents such as PDDs (project definition documents) and SOOs (statements of objectives) often serve the same purpose as capability scopes.

  Capability scope documents describe the "who, what, when, and why" of the project and include information needed for project planning. Capability scope documents cover most of the following topics. Some top-level information for the scope can be found in the operational needs and concepts information from the user community.

• Purpose: What problem is the customer trying to solve? What does the customer need and want? What will this project achieve?
• Value Proposition: Why is this capability justified?
• Objectives/Goals: High-level goals that can be measured.
• Sponsor: Who is paying for the capability?
• Customers: Who will use the results of the project?
• Scope of Project: Activities and deliverables included in this project.
• Out-of-Scope: Activities and deliverables not included in this project.
• Interfacing: What are the interfacing capabilities, systems, or user communities that will touch this project?
• Major Milestones: Events denoting progress in the project life cycle (e.g., completion of key deliverables or important activities).

• Discover and elicit requirements from all relevant sources. The SE collects requirements from many sources, including but not limited to experienced and new users, other stakeholders, SMEs, managers, and, if necessary, the users' customers. Operational users are key contributors because they provide some or all requirements for the system's functional and performance capabilities and user interface. Their inputs are essential to delivering a product, system, or service that helps improve their efficiency by enabling them to easily access the data they need when they need it. The SE elicits requirements directly or indirectly based on users' informal narratives, observing the user environment, or capturing their responses to targeted questions. The SE wants to learn about the operational users' environments and needs a lot of information for that purpose such as detailed descriptions of users' daily, weekly, monthly, and other periodic tasks; documentation (e.g., training manuals); reporting requirements and examples of written reports; preconditions and/or triggers for taking various actions; workflows and sequencing of specific tasks they perform; external and internal rules they must follow, including security requirements; interactions with other operational users, staff members, systems, and customers; type and frequency of problems they encounter; and, overall, what does and does not work for them currently. Users' responses to "describe your ideal system" may open up areas not previously considered. The SE can confirm requirements collected and possibly uncover new ones if given the opportunity to directly observe users doing their jobs. Passive observation is often time well spent.

  The SE consults with SMEs to ensure that system, security, and operational requirements are complete and feasible; the SE also brings attention to and incorporates into the requirements any government and other regulations that must be taken into account during the program. Project size and type, complexity, schedule, number of interviewees, and locations will determine the techniques best suited to eliciting requirements for this project. Techniques include direct observation, one-on-one and/or group interviews, brainstorming sessions, focus groups, surveys and targeted questions, and prototyping. Joint (users, developers, integrators, systems engineering) requirements gathering sessions are frequently one of the most powerful techniques for eliciting requirements. When SEs analyze related documents, system interfaces, and data, they are likely to discover new requirements. Reverse engineering may be needed to uncover requirements for legacy systems that are poorly or not documented. Collection activities proceed to the next life-cycle step (e.g., beginning system design) when users confirm that the implementation of the current set of requirements will meet their needs and project staff agrees that they can build a viable product based on these requirements. However, with many changes in the stakeholders' operations, a continuous requirements collection and refinement effort is needed to ensure that initial requirements are captured and future capability assessments are started by examining the next evolution of requirements due to change, increased certainty in need, or a phased implementation approach.

  Document requirements' types and attributes. Categorizing and organizing many requirements can be daunting. As the process matures, requirements' attributes must be documented and kept up to date to remain traceable during testing, validation, and verification. This process helps SEs and others identify duplicate, missing, and contradictory requirements. Attributes most often tracked are these requirements: ID (number), description, type (e.g., functional, non-functional, performance, explicit, derived, system, operational), priority (e.g., mandatory, desirable), phase (threshold or objective), level of risk, business value (e.g., high, medium, or low), source (e.g., stakeholder, regulation, interface specification), rationale for including the requirement (e.g., improves performance), name of implementer, level of effort, status (e.g., proposed, approved, verified, closed), and, later, release number/release date.

  Model requirements for validation. Stakeholders are frequently asked to review documents that include those requirements for which they are responsible. Stakeholders sometimes need help interpreting requirements; they also expect and are entitled to receive clear explanations of outcomes when they are implemented. Explanations can be facilitated by creating "as is" and "to be" process flows, activity diagrams, use cases, entity relationship diagrams, workflow models, and flowcharts. Models can also be in the form of prototypes or experiments to provide a limited functioning context where users can try out various alternatives, and together the user and SE can assess the requirements (see the SEG article Special Considerations for Issues of Uncertainty: Prototyping and Experimentation). Visual aids that focus on these areas tend to engage the stakeholders' interest. Models show stakeholders how the requirements they contributed represent their statements and goals and are complete and consistent. Agreeing on the meaning of each requirement and its effect on the final product may call for several iterations of discussions, modifications, and reviews by different groups of stakeholders. Putting everyone on the same page takes time. SEs update requirements when changes are made at reviews and meetings, and they track issues (e.g., action items) and conflicts. When conflicts cannot be resolved, SEs bring them to the customer's or sponsor's attention, using other levels of MITRE management, as appropriate.

  Prioritize requirements. As the collection process winds down, stakeholders are asked to assign a priority to each requirement. There may be differences of opinion about which ones are mandatory, critical, desirable, or optional. It is up to the SE to define each priority (e.g., needs vs. wants), point out inappropriate priorities, and suggest changes based on knowledge of this particular project and past experience. Prioritization ends when stakeholders reach agreement. Getting stakeholders to reach agreement can be difficult. A best practice is to develop and put in place a stakeholder contention adjudication protocol early in the requirements elicitation process. Identifying critical requirements is particularly important when evaluating competing systems and commercial-off-the-shelf products. They are also used to evaluate deliverables at various milestones or evolutions, and in projects developed incrementally, they help determine which requirements are included in each phase.

  Work toward getting final agreement from contributing stakeholders. At the end of the requirements collection process, plan to hold a face-to-face requirements review meeting attended by stakeholders who contributed requirements. Include project team members if possible. Often, last-minute requirements changes are needed to reach consensus that they are complete and correct. At that point, requirements are considered "baselined," "locked," or "frozen." But be careful—flexibility is needed throughout the life cycle to ensure that system development and implementation do not try to meet the exhaustive set of requirements when earlier delivery or perhaps reduced costs could be achieved, which is why the prioritization step is very important.

  Document requirements for final approval. The requirements document or specification will dictate much of the project's future work. Before the specification is approved, ask reviewers who know the characteristics of "good" requirements to review it. Good requirements are unique and uniquely identified, necessary, consistent, complete, traceable, testable, implementation-free, attainable, unambiguous, and verifiable. It may be necessary to modify or delete "bad" requirements and their dependents. Dependent requirements are associated requirements, many times implicit or emerging from a functional requirement (e.g., need for data would drive a technical need for some form of database/repository). The executive sponsors or one of the customers make the final approval. Inevitably, implementers, many of whom may be seeing the specification for the first time, will misinterpret some of its requirements. To avoid or minimize misinterpretations, the SE, optimally together with the user community, must be given time to go over the approved specification with designers, software engineers, quality assurance staff, testers, and others to answer questions. As soon as possible, a close community of users, SEs, designers, developers, integrators, and testers should be formed and maintained.

  Capture lessons learned. When a project ends, project members, including managers, are encouraged to document their experiences, good and bad. A facilitator conducts a lessons learned review with project participants to identify best practices and processes that need improvement.

• Dates: When are deliverables due? What are the planned milestone dates?
• Critical Assumptions: Assumptions underlying plans for conducting and completing the project.
• Risks: Potential changes in the project's environment or external events that may adversely affect the project.
• Issues: Issues that have already been identified for this project.
• Constraints: Rules and limitations (e.g., time, resource, funding) that may dictate how the project is carried out.
• Success Criteria: Outcomes that meet requirements, targets, and goals and satisfy the customer.
• Discover and elicit requirements from all relevant sources. The SE collects requirements from many sources, including but not limited to experienced and new users, other stakeholders, SMEs, managers, and, if necessary, the users' customers. Operational users are key contributors because they provide some or all requirements for the system's functional and performance capabilities and user interface. Their inputs are essential to delivering a product, system, or service that helps improve their efficiency by enabling them to easily access the data they need when they need it. The SE elicits requirements directly or indirectly based on users' informal narratives, observing the user environment, or capturing their responses to targeted questions. The SE wants to learn about the operational users' environments and needs a lot of information for that purpose such as detailed descriptions of users' daily, weekly, monthly, and other periodic tasks; documentation (e.g., training manuals); reporting requirements and examples of written reports; preconditions and/or triggers for taking various actions; workflows and sequencing of specific tasks they perform; external and internal rules they must follow, including security requirements; interactions with other operational users, staff members, systems, and customers; type and frequency of problems they encounter; and, overall, what does and does not work for them currently. Users' responses to "describe your ideal system" may open up areas not previously considered. The SE can confirm requirements collected and possibly uncover new ones if given the opportunity to directly observe users doing their jobs. Passive observation is often time well spent.
• The SE consults with SMEs to ensure that system, security, and operational requirements are complete and feasible; the SE also brings attention to and incorporates into the requirements any government and other regulations that must be taken into account during the program. Project size and type, complexity, schedule, number of interviewees, and locations will determine the techniques best suited to eliciting requirements for this project. Techniques include direct observation, one-on-one and/or group interviews, brainstorming sessions, focus groups, surveys and targeted questions, and prototyping. Joint (users, developers, integrators, systems engineering) requirements gathering sessions are frequently one of the most powerful techniques for eliciting requirements. When SEs analyze related documents, system interfaces, and data, they are likely to discover new requirements. Reverse engineering may be needed to uncover requirements for legacy systems that are poorly or not documented. Collection activities proceed to the next life-cycle step (e.g., beginning system design) when users confirm that the implementation of the current set of requirements will meet their needs and project staff agrees that they can build a viable product based on these requirements. However, with many changes in the stakeholders' operations, a continuous requirements collection and refinement effort is needed to ensure that initial requirements are captured and future capability assessments are started by examining the next evolution of requirements due to change, increased certainty in need, or a phased implementation approach.

• Document requirements' types and attributes. Categorizing and organizing many requirements can be daunting. As the process matures, requirements' attributes must be documented and kept up to date to remain traceable during testing, validation, and verification. This process helps SEs and others identify duplicate, missing, and contradictory requirements. Attributes most often tracked are these requirements: ID (number), description, type (e.g., functional, non-functional, performance, explicit, derived, system, operational), priority (e.g., mandatory, desirable), phase (threshold or objective), level of risk, business value (e.g., high, medium, or low), source (e.g., stakeholder, regulation, interface specification), rationale for including the requirement (e.g., improves performance), name of implementer, level of effort, status (e.g., proposed, approved, verified, closed), and, later, release number/release date.

  Model requirements for validation. Stakeholders are frequently asked to review documents that include those requirements for which they are responsible. Stakeholders sometimes need help interpreting requirements; they also expect and are entitled to receive clear explanations of outcomes when they are implemented. Explanations can be facilitated by creating "as is" and "to be" process flows, activity diagrams, use cases, entity relationship diagrams, workflow models, and flowcharts. Models can also be in the form of prototypes or experiments to provide a limited functioning context where users can try out various alternatives, and together the user and SE can assess the requirements (see the SEG article Special Considerations for Issues of Uncertainty: Prototyping and Experimentation). Visual aids that focus on these areas tend to engage the stakeholders' interest. Models show stakeholders how the requirements they contributed represent their statements and goals and are complete and consistent. Agreeing on the meaning of each requirement and its effect on the final product may call for several iterations of discussions, modifications, and reviews by different groups of stakeholders. Putting everyone on the same page takes time. SEs update requirements when changes are made at reviews and meetings, and they track issues (e.g., action items) and conflicts. When conflicts cannot be resolved, SEs bring them to the customer's or sponsor's attention, using other levels of MITRE management, as appropriate.

• Prioritize requirements. As the collection process winds down, stakeholders are asked to assign a priority to each requirement. There may be differences of opinion about which ones are mandatory, critical, desirable, or optional. It is up to the SE to define each priority (e.g., needs vs. wants), point out inappropriate priorities, and suggest changes based on knowledge of this particular project and past experience. Prioritization ends when stakeholders reach agreement. Getting stakeholders to reach agreement can be difficult. A best practice is to develop and put in place a stakeholder contention adjudication protocol early in the requirements elicitation process. Identifying critical requirements is particularly important when evaluating competing systems and commercial-off-the-shelf products. They are also used to evaluate deliverables at various milestones or evolutions, and in projects developed incrementally, they help determine which requirements are included in each phase.

  Work toward getting final agreement from contributing stakeholders. At the end of the requirements collection process, plan to hold a face-to-face requirements review meeting attended by stakeholders who contributed requirements. Include project team members if possible. Often, last-minute requirements changes are needed to reach consensus that they are complete and correct. At that point, requirements are considered "baselined," "locked," or "frozen." But be careful—flexibility is needed throughout the life cycle to ensure that system development and implementation do not try to meet the exhaustive set of requirements when earlier delivery or perhaps reduced costs could be achieved, which is why the prioritization step is very important.

• Document requirements for final approval. The requirements document or specification will dictate much of the project's future work. Before the specification is approved, ask reviewers who know the characteristics of "good" requirements to review it. Good requirements are unique and uniquely identified, necessary, consistent, complete, traceable, testable, implementation-free, attainable, unambiguous, and verifiable. It may be necessary to modify or delete "bad" requirements and their dependents. Dependent requirements are associated requirements, many times implicit or emerging from a functional requirement (e.g., need for data would drive a technical need for some form of database/repository). The executive sponsors or one of the customers make the final approval. Inevitably, implementers, many of whom may be seeing the specification for the first time, will misinterpret some of its requirements. To avoid or minimize misinterpretations, the SE, optimally together with the user community, must be given time to go over the approved specification with designers, software engineers, quality assurance staff, testers, and others to answer questions. As soon as possible, a close community of users, SEs, designers, developers, integrators, and testers should be formed and maintained.

• Capture lessons learned. When a project ends, project members, including managers, are encouraged to document their experiences, good and bad. A facilitator conducts a lessons learned review with project participants to identify best practices and processes that need improvement.