Using SDLC Phases for Status Updates - IT Projects

With RequisitePro you can add SDLC Phases to improve the likelihood of a successful IT project through real-time status updates. This post provides information on RequisitePro attributes and it tells how to add the SDLC Phases and SDLC dates to make IT project management easier. It then provides a detailed overview of the Software (or System) Development Life Cycle, which is the overall processes used to conceive, plan, define, design, build, test and deploy a software application or business system.

In RequisitePro you can use pre-established attributes for each requirement type; or, you can add your own attributes. Attributes provide additional information about requirements so software developers do a better job of developing, testers do a better job of testing, analyst do a better job managing and IT project managers do a better job of monitoring. Below is what some of the the out-of-the-box use case attributes look like in IBM Rational RequisitePro.

Notice, at a glance, you can see the normal flow, alternate flows, includes, extends, etc. for each use case. If you configure RequisitePro to handle all of the attributes included in the Use Case Specification you can then distribute the printouts from RequisitePro instead of creating the Specification.This approach is useful if the IT project manager wants to reduce the time typically spent creating requirements documents. Also, if you look at the title for the RequisitePro view you will see it is called “Developer View”. This is because the Developer View contains the attributes that give the developer the same insight he would have if he were to view the use case specification.

Notice, in the picture below the user interface attribute has been added. In this scenario the images are stored on a web server and the URL to the image is included in the user interface field.The developer can use a web browser to view the mockup image and either store the image locally or continue to use the web browser.

By default, the use case attributes include the priority column. This ensures all requirements associated with a “High” priority are implemented before those associated with a “Medium” priority and so forth. In other words, using this RequisitePro view a software developer can look at the list and identify the requirements that must be implemented first (high), second (medium) and last (low).

The following picture shows additional attributes that can be associated with a requirement such as the SDLC Phase attribute and the SDLC date. These attributes are displayed on the Status Report view created specifically to convey the status of each requirement.

By adding the SDLC (Software or System Development Life Cycle) Phase to RequisitePro, the customer or IT project manager can look at the Status Report view to tell exactly what SDLC phase a requirement is in. In addition, the SDLC Date field defines the date the requirement entered the SDLC Phase. Notice, in the above picture you can tell what requirements are being tested, what requirements are in the design phase and what requirements are still in planning or the requirements analysis phase. The good thing about this view is an IT project manager can tell, at a glance, if certain deliverables will not be developed within the agreed upon time-frame. For example, if the due date for delivering the ability to "add a project" is to be implemented by June 30, 2013 and as of May 29, 2013 the requirement just entered the Requirements Analysis Phase the IT project manager can address the problem. In this scenario, the IT project manager can either renegotiate the deadline or request that everyone work longer hours to meet the timeline initially agreed upon. Lastly, in the above picture, the software being developed is called TMS (Time Management System). A column called TMS Release has also been added. This column allows us to assign a release to each use case (for the IT projects using an iterative approach).

Now, for those of us who like refreshers the following paragraphs include a brief overview of the phases that make up the SDLC. Note that the following phases may vary some across Federal Government agencies. But the overall concept remains the same (i.e., you must plan a project, define the requirements, design the software component(s), build the software components, test the software , deploy it so users have access, and then maintain it).

The following paragraphs present a more detailed view of the the SDLC Phases and it includes information on the objectives of the phases as well. Overall the artifacts developed depend largely on an organization’s implementation of the SDLC.

• Initiation Phase: During this phase the organization conceives a software idea that addresses a need or problem. The goals of this Phase are to establish project sponsorship, develop a concept proposal, assign a project manager to the project, identify a group that will serve as the planning team, and perform an initial analysis of the associated business process and improvement areas, which may include automating some process steps. The information gathered from this phase is used as a foundation to determine whether or not it is feasible to move on to the next phase.

• System Concept Development Phase: The primary objective of this phase is to identify the boundaries or scope of the project. If funding is needed, this is the phase in which it is requested. Additional activities associated with this phase include analyzing the business need, assessing the alternatives, identifying project risks, defining the roles and responsibilities of the planning team, developing the initial IT project plan with milestones, defining the project success criteria and writing a high-level statement on how the IT project will meet its success criteria.

• Planning Phase: The primary objective of the Planning Phase is to create all of the necessary project management plans so the project begins with a structured, implementable plan to increase the likelihood of success. During this phase the project organizational structure is defined (i.e., who fills what role and who reports to whom). In addition, a few of the IT project management plans created include the risk management plan, staffing plan, requirements management plan, communication plan, problem resolution plan, architecture plan, change management plan, configuration management plan, test plan, deployment plan, etc.

• Requirements Analysis Phase: The Requirements Analyst Phase is used to gather requirements, manage the requirements, write the requirements artifacts, analyze the requirements for gaps and ask the questions necessary to close gaps. If an iterative approach will be used, this phase will be repeated until all requirements have been gathered and added to the requirements management system. In addition, configuration management may be used to ensure the documentation is properly mapped to development releases and controlled releases ensure the promised software functionality is delivered in the proper release. With configuration management version control must be applied.

• Design Phase: The objective of this phase is to translate the requirements into an implementable design. UML diagrams may be used and/or a design document may be developed. The result should be requirements tied to objects and behaviors that the software development team can implement.

• Development Phase:  The core activities associated with this phase include coding the software components, performing unit tests and integrating the components to build a solution (partial or whole) that can move into testing. 

• Integration & Test Phase: This phase is used to perform all required testing to ensure the software works properly and contains the requested functionality. Testing may include user acceptance, functional, system transactional, regression, etc.

• Implementation Phase: During this phase, the team deploys the software so users can access it. Release notes are distributed to end users to inform them of any updates, known defects, etc. Also a communication is sent to end users informing them of the day/time the new/updated software will be available. If this is the first time users will access the software, the location or URL needed to access the software is also provided. Once the software is deployed, the IT project team may host a meeting to document lessons learned so future implementations will be more concise and correct.

• Operations & Maintenance Phase: Key activities performed during this Phase include change management and associated activities used to make changes to the software after it has been deployed to users. In addition, a Change Management plan should have been created during the project planning phase. This is the phase in which that plan is executed. If a help desk exists, it is usually the first tier to troubleshoot software problems. If the help desk (or Tier 1) is not able to resolve the problem, the ticket is escalated to the more seasoned analyst team (called Tier 2). If Tier 2 cannot resolve the problem, the ticket is escalated to Tier 3, which is the development team. Tickets solved at Tier 1 are far less costly than those solved at Tier 3. This is one key reason IT project teams try to release software with as few known defects as possible. Also, missing functionality is addressed during this Phase. An end user may submit a change request to ask for functionality not yet implemented. If this occurs a business analyst (or systems analyst) will talk with the end user and other persons, as necessary, to gather the requirements to be implemented.

• Disposition Phase: The Disposition phase provides structured activities that should be followed if a software or hardware component is outdated; or, for some other reason is no longer needed. There are procedures that should be followed to ensure any data is archived, destroyed or migrated to another system, as necessary.

Summary

In this post you learned that you can either use pre-existing attributes in RequisitePro; or, you can add your own attributes. We added the SDLC Phases and then we added the SDLC Date attribute to RequisitePro. As the requirements move through the SDLC, RequisitePro is updated to reflect the SDLC phase the requirement is in and the date in which the requirement entered that phase. This approach makes it easier to support IT project activities surrounding deliverables and timelines. In addition, a Release column can be added to RequisitePro so the requirements can be associated with a specific release to support iterative development activities.

How to Write Implementable, Testable, Accurate Use Cases

In this article I discuss how to write use cases that accurately reflect what stakeholders want and ensure the use cases are implementable and testable.

Definition of a Use Case

First, let's define a use case. A use case is a group of words that depict system behaviors or actions. Put another way, a use case defines an action the user can perform using a system or software application. When stakeholders discuss the tasks they want users to complete using a software product, the information may or may not be stated in the form of a use case. But, there are several rules you can apply to define use cases, from stakeholder statements, more easily: 1. always start the use case with an action word; 2. each use case should always define a single action; and, 3. each use case should convey a task a user can use a computer to perform.

Accurately Capturing Use Cases

To accurately capture the actions stakeholders want users to perform you have to talk to stakeholders. It's a very good practice, whenever possible; to record the requirements gathering sessions so you can later verify what you "think" you heard in the meeting. Capturing the information directly from the source is a great start in your endeavor to ensure the requirements are accurate. Note that you will still need to validate the use cases by circulating them for review and approval.

Once you understand the actions the stakeholder wants to perform using the system, you can review the statements to create the use cases. Remember each use case must provide an action a user can perform when sitting in front of the computer. For example, "unable to enroll a student because of outstanding debt" is not a use case. A user cannot sit in front of a system and use it to "unable to enroll a student because of outstanding debit". The user can, however, sit in front of a computer and use it to "deny a student’s enrollment". Ensuring requirements are documented as an actionable statement is likely the reason user stories are gaining popularity. When you write user stories you begin with a phrase: As an "actor" I can "perform this task"... This approach forces everyone to think "what actions do I want to perform when using the software?"

In our previous example, we said a user can sit in front of a software application and use the software to "deny a student's enrollment request". Denying the student's enrollment "because of outstanding debit" can be one scenario in which the student's enrollment is denied. However, there could also be other reasons why the enrollment is denied. For example, a student's enrollment might be denied because "the student's SAT scores are too low". So you could have a use case: Deny Enrollment and use the Normal and Alternate flows to depict the scenarios.

Once you have defined the use cases that outline the actions users should be able to perform, there’s still more work to do. You will need to uncover additional use cases required to build a complete system. For example, let's say a stakeholder told you he wants a system that can "track employee hours for each project to accurately manage project costs". In this example we know exactly what the business objective is. Further elicitation sessions helped us identify specific actions users should be able to perform as follows:

• Approve and Disapprove Time-sheets manually (as well as automatically approve time-sheets).
• View Project Hours by Customer 
• View project tasks by employee; and, view the number of hours each employee spends on a project task. 
• Generate Project Cost Reports based on employee project hours 

We can carefully analyze the information and break the statements into single actions the user can perform:

• Approve time-sheets (manually and through automation)
• Disapprove time-sheets (manually only)
• View Project Hours by customer
• View Project Hours by Project Task
• View Project Tasks by Employee
• Generate a Project Cost Report (Based on the information provided we know we have to include the employee’s hourly cost multiplied by the hours worked. But, we don’t know what date range should be used for this report. In the real world we would have to ask more questions. For this article we are going to focus on the first five actions.)

We can rename the Approve Time-sheets and Disapprove Time-sheets by creating a Sign-Off on Employee Time-sheet use case. We can handle the approve and disapprove scenarios through the normal and alternate flows. Since we must define separate requirements to automate approving a time-sheet "Automatically Approve a Time-Sheet" can be a child or an "extends" use case of the "Sign-Off on Employee Time-Sheet". We were also informed of the condition that must be present for automation to occur. An employee's work hours must be equal to or less than 40 hours for a single work week.(In the real world this last statement would be a functional requirement.)

Next we need to combine View Project Hours by Customer and View Project Hours by Project Task into one use case. Both use cases perform the exact same action "View Project Hours". The only difference between the use cases is the data (i.e., in one scenario (such as the normal flow) users view project hours by customer; however, in the other scenario (such as the alternate flow) users view project hours by project task).

We can name our last use case View Project Tasks. In our use case description we can point out that the project tasks should be viewable by employee.

Sign-Off on Employee Time-sheet

Here we look at the "Sign-Off on Employee Time-Sheet" use case in greater detail. In this example we will design the use case so the normal flow is used to "mark time-sheet as approved". The alternate flow is used to "mark time-sheet as disapproved". We also need to capture more information from stakeholders so we can more clearly define all of the functionality to be provided by the software. For example, what data elements do stakeholders want the time-sheet to display? So far we've only discussed project tasks and project hours. But we also know each employee has to complete a time-sheet; and, there is likely additional data the timesheet must capture. Note that your requirements management tool can be used to manage questions to make sure we track what questions we've received answers to. The following picture shows the Gap Analysis folder that includes the QUES type used to manage questions.

QUES Requirements Type Added to Requirements Management System to Manage Questions/Responses

 
When we sit with the stakeholder we have pencil and paper in hand. We need to find out what the stakeholder envisions the time-sheet to look like. In other words what data will the time-sheet capture? As we discuss the data elements that should be included we can draw the fields on the piece of paper. Again, we are capturing what the stakeholder wants during the discussion to make sure the information is accurate.

The stakeholder decides the time-sheet should have the employee’s name, the name of the project, the project tasks assigned to the employee and the number of hours spent on each task. This could present a problem. If we only use the employee’s name, what happens when two employees have the same name? We could use the employee’s first name, last name and user’s Windows Log-in ID. We also learn that the Project Manager assigned to the project will review and approve time-sheets. This tells us there must be a way to associate the project manager with the project. If we created a rough sketch during the meeting; we can show it to the stakeholder. The stakeholder may agree or even make changes. Either way this will give us the information we need to define the time-sheet. Below are the fields we captured for the time-sheet:

• Employee’s first and last name and Windows Log-In ID
• Project Name 
• Project Tasks 
• Hours Worked 
• Project Manager Name

We know Hours Worked can be any value from 0 to 24 for each day. We don’t know what value the user will enter so we can’t recommend reuse for this field. We're fairly sure the company doesn't want employees to manually enter their own name, the project name, the project tasks or project manager name for two reasons: 1. To generate reports data must be consistent. If users type in a value such as project name or project tasks some people will abbreviate the values, some will miss-spell one or more words and some will get it right. Therefore if a user wants to see all reports for a specific project, it would not be possible. This is because some users would have spelled the project name incorrectly. Others may even abbreviate the project name. 2. It's more time-consuming to have each employee enter the same values into a textbox. Alternatively, the system can be built so the values are entered once. User can then select the desired options from a  list of options.

We can now create the additional use cases needed to support the "Sign-Off on Employee Time-sheet" use case:

• Add a Project (This use case provides the functionality that lets Project Managers add project names. It is also conceivable that the ability to Search Projects or even Edit Projects may be necessary, depending on the Vision for the system. )
• View a List of Projects (Users must be able to view a list of projects to select the correct project.)
• Add Project Tasks (This use case lets the Project Manager add project tasks for each project.); and
• View a List of Project Tasks (Users must be able to view a list of project task to select the proper tasks.)

We would also need to add a requirement to ensure the employee’s first, last name and Windows Log-In ID are automatically added to the timesheet when the user creates it.

In Conclusion

To accurately capture requirements it is best to host a requirements gathering session. And, it takes close communication to ensure the requirements are accurate. Making assumptions in a vacuum and circulating those assumptions without getting feedback first may lead to mistrust—depending on how well the stakeholders know you. Always confirm assumptions before circulating the assumptions. Clear communication is a great way to build trust and get the requirements right.

Lastly, as you name use cases give careful thought to the use case name. The name should identify a single action the user can perform while using the system. This approach ensures developers can implement the use cases and testers can test them with a specific objective in mind. And, in the end everyone knows exactly what to expect because the use cases are not ambiguous.

Requirements: Writing Use Cases

Use Case Overview

A Use Case is a requirement that directly relates to a user's or system's ability to do something. The something a user does may include creating a record, deleting a record, editing a record, searching for a specific  record, logging into a system, generating a specific type of report, exporting a data, etc. Some projects use user scenarios instead of use cases. However, many projects still use use cases because this type of requirement has been around longer and provides clearer direction when creating requirements. Use Cases are typically included in a document called the Use Case Specification.

Use Case Properties

Use Cases also have properties. A property is text that provides specific information about the use case. For example Use Case Name and Use Case Description are both properties, Following is a list of the Use Case Properties:

ID:  The identify of the use case. Each use case has a unique identifier such as 1, 2, 3, 4, or 1.0, 1.1, 2.0, etc.

Name:  A unique name for the use case. Examples: Add a Customer Record, Update a Customer Record, Mark a Customer Record as Inactive (which is associated with the update task), Search Customer Records, Filter Customer records, Generate a Customer Orders Report.

Description:  This field provides additional information about the use case.

Date: The date the use case was created or updated.

Actor(s): The user group that will be able to perform this use case. For example, user groups can be HR secretaries, HR Benefits Managements, Accounts Receivable Clerks, Desktop Publishers, teachers, principals, students, parents, etc.

Pre-condition: The condition the system is in before the use case is executed. For example the system might be in a "Validated" state if it is about to store data; but was required to validate the data first.

Post-condition: The condition the system is in after the use case has been executed. For example, if the system just filled an order it might be in the "order filled" state.

Normal Flow: This property outlines the steps the user executes to complete the task defined by the use case. For example, Create a Customer Record the user my 1. Log into the system; 2. Select Customer Management (from the menu); 3. Select Create Customer from the Customer Management page; 4. Enter customer information; 5. Click Save to save the record and return to the Customer Management page.

Alternate Flow: This property outlines any alternate paths a user might take to execute the use case. For example, users might perform step 1 from the normal flow. Then for step 2 users may right click and select Import to import a customer record.  Since users are performing a step differently, this is known as a branch. A branch is used whenever users perform the same task (in this case, Create a Customer Record) differently. Step 3 then says "return to step 5. Normal flow". So the alternate flow only outlines were steps differ from the normal flow.

Includes: This property outlines the Use cases this use case includes or uses. To execute the Create a Customer Record use case users must first  "Log into the system," which is also a use case that defines logging in requirements. Whenever users must perform the steps in another use case to complete the current use case; the current use cases uses or includes another use case.

Extends: When a use case extends another use case the extending use case adds additional functionality to  the base use case. For example, a toy manufacturer may have a program where customers (who meet a certain criteria) can use points they've earned to buy beta toys. Ordering beta toys requires different functionality from the functionality required to order regular toys. For example, customers cannot use money or credit cards to buy beta toys--making the payment method different. Customers cannot purchase beta toys from the regular product stock--making the location where toys are stocked different. In addition customers can't backorder or pre-order beta toys. And, customers must meet a certain criteria  to view the available beta toys. Therefore, there should be a use case that supports the functionality to "Place an Order". The "Order Beta Toys" use case would extend the "Place an Order" use case.

Business Rule(s): Many companies establish business rules. Some business rules must be enforced by a system; while other business rules cannot be enforced by a system. If a business rule is to be implemented or enforced by a system; it is associated with the applicable use case.  Examples of Business Rules are as follows: 1. An employee must work for the company for 3 years before he/she can enter a customer order into the system. 2. A Customer Service Manager must approve the order before the products are shipped. (Note that both of these business rules can be implemented by the system.)

Feature(s): The feature is the highest level of requirement. Features are used to group a use case. Examples of features include Generate Reports, Manage Customer Records, Interface With Accounting System, etc.

The Use Case Specification

Use Cases are typically added to a Use Case Specification. The Use Case Specification is a document that includes the use cases along with the property details for each use case. Once the Use Case Specification is completed; it is distributed to the users or user representatives for review and feedback.

Requirements: Understanding the Customer's Vision

Establishing the Vision

One of the most important aspects of designing a system is requirements gathering. A company can have the most seasoned user experience professionals, top-notch developers and exceptional testers that catch every defect. But, will the customer be happy with a beautifully built, flawless product that isn't what was needed? Probably not!

For over 8 years I've worked as a business systems analyst; typically hired as a consultant after a project has failed. And, in most cases, the projects that failed did so because incorrect assumptions were made. And, requirements were then written from a mixture of inaccurate assumptions and customer statements.

The only way to accurately identify customer requirements is to ask questions. Ask questions and let the customer state his/her vision for the implementation. Be sure to ask about business problems and needs that may have initiated the need for the project. You can manage this information by creating a list of business problems and/or needs. Ultimately, all requirements and problems/needs should be managed using a requirements management system such as RequisitePro.

 

Problem/Needs List

1.1 NEED:  Need a dashboard that reflects current sales by region

 

1.2 PROBLEM: Currently, end users are not able to associate a customer order with a region (data can only be associated with a city and state). Should we have the system assign the region based on the city/state? How can we fix this problem?
1.3 NEED:  Need to be able to generate reports for segment marketing. We need to implement a business intelligence solution.
1.4 PROBLEM: All employees can add order records, when only Customer Support should be able to add order records. What’s the best way to address this problem?

 

Notice, with each problem the customer realizes that it’s a problem; but the need that will be used to fix the problem has not been identified. Ultimately, all problems should be translatable to a definite need that everyone agrees on. Following is the updated Problems/Needs list with the problems translated to a need. (Note that with requirements it is good to keep all of the information in place and add notes as changes are made. Then as questions arise as to where the requirement came from, you have the historical data to refer to.)

Problem/Needs List UPDATED

1.1 NEED:  Need a dashboard that reflects current sales by region
1.2 NEED:  Add region data added to the database.  Need to get the CD from the Post Office that includes city, states and zip codes. Verify that the region data is also included. If not our DBAs will need to add the region data.  (Description for the need is: This need resolves 1.2 Problem:  Currently, end users are not able to associate a customer order with a region (data can only be associated with a city and state). Should we have the system assign the region based on the city/state? How can we fix this problem?)
1.3 NEED:   Need to be able to generate reports for segment marketing. We need to implement a business intelligence solution.
1.4 NEED:   Need a Customer Support Role. This role should be the only role with the right to add a customer order. No other roles should be granted this right. .  (Description for the need is: This need resolves 1.4 Problem: All employees can add order records, when only Customer Support should be able to add order records. What’s the best way to address this problem?)

 

Once the problems/needs list has been completed you will need to ask about the Features the system is to support. Features are the highest level of requirements.  The features will ultimately be used to organize the use cases.

Following is a list of features to provide an example of what a feature might look like:

 

Produce Features

 

1.     Manage Customer Records

2.     Interface with the XYZ Accounting System

3.     Generate Business Intelligence Reports

4.     Manage Sales Records

5.     Manage Employee Records

6.     Manage Customer Orders

 

Both the Problems/Needs list and the Product Features are added to the Vision document, which includes other information such as information about the stakeholders (individuals who are directly impacted by the success or failure of the projects). The Analyst should ask stakeholders whether or not they have any type of success criteria. A success criterion is a requirement that the system or project must meet for the project to be viewed as a success. For example, a success criterion may be that the system must be in place by a specific date. If this is the case adding a priority to your features, use cases and functional requirements become critical. When you have short timelines, you will need to work with the stakeholders to prioritize the requirements. Requirements marked with a “High” priority are implemented first. Then the “Medium” priority requirements are implemented once all “High” requirements have been successfully implemented. Lastly, your “Low” priority requirements are implemented once the Medium priority requirements have been implemented.  The following table shows an example of the High, Medium and Low priorities mapped to features, use cases and functional requirements.

 

 

Features	Feature Ranking = High	Feature Ranking = Medium	Feature Ranking = Low
Use Cases	All Use Cases = High priority	Approximately %50 of use cases = High priority – ONLY IMPLEMENT THE USE CASES MARKED AS HIGH.	Less than %50 of use Cases = High priority– ONLY IMPLEMENT THE USE CASES MARKED AS HIGH
Functional Requirements	All functional requirements = High priority	Approximately %50 of functional requirements = High priority– ONLY IMPLEMENT THE FUNCTIONAL REQUIREMENTS MARKED AS HIGH	Less than %50  of functional requirements = High priority– ONLY IMPLEMENT THE FUNCTIONAL REQUIREMENTS MARKED AS HIGH

 

 

In addition to adding information about the stakeholders, information about the end users of the system is also included in the Vision document. Other information included in the Vision document includes the technical documentation and end-user training requirements as well as a high-level list of other requirements such a performance. Once the features have been identified, the use cases are defined and added to the use case specification.  Then the functional requirements are defined and added to the software requirements specification.

To accurately design a business solution from requirements; the analyst must take on the role of a detective. He or she must search for unknowns; and, turn mysteries into concrete statements for feedback. At times the analyst will have to draw conclusions from provided information; and, clearly state those conclusions for feedback. Thorough investigative work is what it takes to accurately define a business solution. But it also takes an understanding of the technology associated with the project.

It's also good practice to gain an understanding of any initial groundwork already laid for the project. For example, ask for a copy of the Statement of Work (SOW). Also, ask for existing system documents, system diagrams, and access to the current system, if applicable. And, in some cases, personal time may need to be used to read through the materials--if the deadlines are tight. But, it is worth it to put forth the effort to gain this insight prior to meeting with the customer. This allows requirements gathering sessions to be used to gather requirements.

Summary
Below is a list of tips you may find useful while meeting with customers to understand system requirements:

1. Ask for existing system or project documentation.

2. Be willing to use your personal time to learn concepts if deadlines are tight.

3. When meeting with the customer ask questions. And, make sure the stated business problems/needs are addressed.

4. Enter all requirements into a requirements management system.

5. Perform a gap analysis between the current system, the business problems/needs and the use cases and functional requirements. If a business need has not been translated into an actionable requirements be sure to translate it to either a use case or functional requirements—based on the need and how it is to be implemented.

6. Write questions that will help close the identified gaps. Then be sure to obtain complete answers to those questions.

7. Update the requirements as you receive answers to your questions.

8. Generate a trace matrix or report for customers to review.