8
Khaled Dahleez <[email protected]> Five Things You Need to Know for a Requirements Plan 1 message Danielle Smallwood, TenStep <[email protected]> Wed, Oct 19, 2016 at 4:43 PM ReplyTo: [email protected] To: [email protected] Please click here if you wish to unsubscribe Remember These Five Components of a Requirements Management Plan The Requirements Management Plan describes how you will elicit, analyze, document and manage the requirements of the project. This plan will cover the upfront gathering of highlevel project and product requirements, as well as the more detailed product requirements that you will collect during the project lifecycle. This plan should especially focus on how you will manage changes to the requirements after they have been originally approved. Sections of the plan could include the following information: The requirements gathering process. In this section you will describe the process that you will use to elicit, analyze and document the requirements. Roles and responsibilities. This section lists the roles that will be involved with managing the requirements through the rest of the project lifecycle. Roles could include the project manager, lead analyst, clients, etc. The project manager, for instance, should have the overall responsibility for scope change management of the requirements. Someone, perhaps the lead analyst, should have overall responsibility for the integrity of the requirements throughout the rest of the lifecycle. Tools. Describe any automated tools that will be used to manage the requirements. There are a number of tools that can be used to document, manage and track requirements throughout the lifecycle. Requirements traceability. If your project team is tracking (tracing) requirements from Analysis to Design and through the rest of the lifecycle, the overall process should be described here. This process should then be added to the schedule to ensure the proper tracking of requirements occurs throughout the rest of the project. Change control . There should be a formal process to manage changes to the requirements. Hopefully, the entire project is using a formal scope change process. If so, then this overall scope change process should be specifically applied to the changes in requirements. If there is no formal overall scope change process, a specific change control process should be documented here. Adhering to a Requirements Management Process helps the project team focus on the requirements that have been developed and maintains the integrity of the requirements throughout the lifecycle of the project. .....

Five Things You Need to Know for a Requirements Plansite.iugaza.edu.ps/kdahleez/files/2014/09/Requirements-Analysis.pdf · Five Things You Need to Know for a Requirements Plan

  • Upload
    lyphuc

  • View
    213

  • Download
    0

Embed Size (px)

Citation preview

Khaled Dahleez <[email protected]>

Five Things You Need to Know for a Requirements Plan 1 message

Danielle Smallwood, TenStep <[email protected]> Wed, Oct 19, 2016 at 4:43 PMReply­To: [email protected][email protected]

 

This weekly "tips" email currently has over 400,000 readers. Please click here if you wish to unsubscribe

Remember These Five Components of a  Requirements Management Plan

The Requirements Management Plan describes how you will elicit, analyze, documentand manage the requirements of the project. This plan will cover the up­front gatheringof high­level project and product requirements, as well as the more detailed productrequirements that you will collect during the project lifecycle. This plan shouldespecially focus on how you will manage changes to the requirements after they havebeen originally approved. Sections of the plan could include the following information:

The requirements gathering process.  In this section you will describe theprocess that you will use to elicit, analyze and document the requirements.

Roles and responsibilities. This section lists the roles that will be involved withmanaging the requirements through the rest of the project lifecycle. Roles couldinclude the project manager, lead analyst, clients, etc. The project manager, forinstance, should have the overall responsibility for scope change management ofthe requirements. Someone, perhaps the lead analyst, should have overallresponsibility for the integrity of the requirements throughout the rest of thelifecycle.

Tools. Describe any automated tools that will be used to manage therequirements. There are a number of tools that can be used to document,manage and track requirements throughout the lifecycle.

Requirements traceability. If your project team is tracking (tracing)requirements from Analysis to Design and through the rest of the lifecycle, theoverall process should be described here. This process should then be added tothe schedule to ensure the proper tracking of requirements occurs throughout therest of the project.

Change control. There should be a formal process to manage changes to therequirements. Hopefully, the entire project is using a formal scope changeprocess. If so, then this overall scope change process should be specificallyapplied to the changes in requirements. If there is no formal overall scopechange process, a specific change control process should be documented here.

Adhering to a Requirements Management Process helps the project team focus on therequirements that have been developed and maintains the integrity of the requirementsthroughout the lifecycle of the project.

.....

The TenStep Suite ­ Customize ­ Deploy ­ Manage

Manage your project from start to finish with the TenStep Suite ­ Methodology andmore. The TenStep Suite contains what you need to both manage projects and to trainpeople on how to run the projects.

 

Copyright © TenStep, Inc.Follow us on:

   

 

This message was sent to [email protected] from:

Danielle Smallwood, TenStep | [email protected] | Tom Mochal | 2363 St Davids Square | Kennesaw, GA 30152

Unsubscribe

Khaled Dahleez <[email protected]>

Use These Four Steps to Gather Requirements 1 message

Danielle Smallwood <[email protected]> Wed, May 13, 2015 at 4:39 PMTo: [email protected]

 

This weekly "tips" email currently has over 400,000 readers. Please click here if you wish to unsubscribe

New E­Class ­ GatheringRequirements

Earn 10 PDUs!

Projects deliverables mustmeet the needs and

expectations of the customerto be successful. Thesecustomer needs and

expectations are set throughthe gathering and agreementon the requirements. Projects

with any degree ofcomplexity need a formal

process to ensure that all ofthe requirements areaccurately gathered,

reviewed, documented andapproved.

Buy this e­class anddownload immediately to

learn the TenStep model forgathering requirements ­elicitation, validation,

specification and verification.

Click here for more detailsand to buy now.  

Use These Four Steps to Gather RequirementsKnowing how to gather requirements is a skill that every analyst, and project manager, ­should have. However, it seems to be a skill that is generally lacking in manyorganizations. Poor requirements gathering is a major cause of project problems inmany organizations. 

Gathering requirements is more than just asking a few questions and then proceeding tothe next step in the lifecycle. We have a four­step process for gathering requirementsthat all projects should utilize to some degree. If your project is small, you will gothrough thee steps quickly. Larger projects may spend quite a lot of time workingthrough the process.

Elicitation. The Elicitation step is where the requirements are first gathered. Toelicit accurate requirements, the analyst must ask the right kind of questions andthen listen carefully to the answers. There are a number of techniques foreliciting requirements and your project may need to use multiple techniquesdepending on the circumstances. This includes interviews, facilitated sessions,prototypes, questionnaires and more. 

Validation. The Validation step is where the "analyzing" starts. The purpose ofvalidation is to make certain that the information conveyed during elicitationaccurately represents the needs and expectations of the clients andstakeholders. The work here includes consolidating requirements, rationalizingthem, looking got overlaps and gaps and creating models to help visualizeprocesses.

Specification. During this step, the analyst prioritizes and formally documentsthe requirements in a Requirements Definition Report. The requirements are alsonumbered in a way that allows them to be tracked through the rest of thelifecycle. Finally, they are checked to make sure that they can ultimately betested.

Verification. The final step in the requirements gathering process is verifyingthat the documented requirements accurately and completely communicate theneeds and expectations of the client. The requirements are reviewed andformally approved. During this step, the analyst can also develop acceptancecriteria and start to write test cases for the final solution.

The truth is that all team members need to appreciate the value of good businessrequirements and should have some fundamental skills in gathering them. Gatheringgood requirements up­front saves time and money and improves the overall quality ofyour product.

................................................

Contact us today to help you implement the right requirements process for yourorganization ­ traditional or Agile. 

..................................................................................

Copyright © 2015 TenStep, Inc.Follow us on:

   

 

This message was sent to [email protected] from:

TenStep Inc | [email protected] | 2363 Saint David's Square | Kennesaw, GA 30152 United States

Unsubscribe

Khaled Dahleez <[email protected]>

Be Smart ­ Use These Seven Techniques to Elicit Requirements 1 message

Danielle Smallwood, TenStep <[email protected]> Wed, Jul 20, 2016 at 4:29 PMReply­To: [email protected][email protected]

 

This weekly "tips" email currently has over 400,000 readers. Please click here if you wish to unsubscribe

Our Treat!

Download 1, 2 or 3 FreeTemplate Sets

Template Collective

 Method123

GetProjectTemplates

Use These Seven Techniques to Elicit RequirementsRequirements are usually gathered in two places during a traditional project. High­levelrequirements help you complete a Project Charter. Detailed requirements are gatheredduring an Analysis Phase. The detailed requirements help you understand how todesign and build the solution. The TenStep requirements gathering model has four steps ­ elicitation, validation,specification and verification.The elicitation step is where the high­level requirements are gathered. To elicit accuraterequirements, the project manager must ask the right kind of questions and then listencarefully to the answers. Gathering requirements through an interview process isprobably the most common technique. However, there a are a number of techniques foreliciting requirements, and your project may need to use multiple techniques dependingon the circumstances. 

1. One­on­one interviews. The most common technique for gatheringrequirements is to sit down with the clients and ask them what they need. Thediscussion should be planned out ahead of time based on the type ofrequirements you are looking for.

2. Group interviews. These are similar to the one­on­one interview except thatthere is more than one person being interviewed. Group interviews require morepreparation and more formality to get the information you want from all theparticipants. You can uncover a richer set of requirements in a shorter period oftime if you can keep the group focused.

3. Facilitated sessions. In a facilitated session, you bring a larger group togetherfor a common purpose. In this case, you are trying to gather a set of commonrequirements from the group in a faster manner than if you were to interview eachof them separately. 

4. JAD sessions. Joint Application Development (JAD) sessions are similar togeneral facilitated sessions. However, the group typically stays in the sessionuntil the session objectives are completed. In this case, the participants wouldstay in session until a complete set of requirements is documented and agreeto. 

5. Questionnaires. These are much more informal, and they are good tools togather requirements from stakeholders in remote locations or those that will haveonly minor input into the overall requirements. A questionnaire can also be a

valuable way to gather quick statistics, such as the number of people who woulduse certain features, or to get a sense for the relative priority of requirements.

6. Prototyping. Prototyping is a relatively modern technique for gatheringrequirements. In this approach, you gather preliminary requirements that you useto build an initial version of the solution – a prototype. You show this to theclient, who then gives you additional requirements. You change the applicationand cycle around with the client again. This repetitive process continues until theproduct meets the critical mass of business needs, or for an agreed number ofiterations.

7. Following people around. This is especially helpful when gathering informationon current processes. You may find, for instance, that some people have theirwork routine down to such a habit that they have a hard time explaining whatthey do or why. You may need to watch them perform their job before you canunderstand the entire picture. In some cases, you might also like to participate inthe actual work process to get a hands­on feel for how the business functionworks today.

Knowing the stakeholders that will provide requirements will help you determine the righttechniques to utilize to best meet your needs. You should select techniques that getyou the most relative information and are best suited for the audience.

........................................................

The Must­See Virtual Class on Implementing Culture Change

Change is hard for both managers and staff. For some people it is almost impossible.And yet, organizations must change to survive. Organizational change management(OCM) is the process used to facilitate the change. OCM can seem daunting at first.This webinar will break down the components so anyone can do it.

Live Virtual Class

Date: July 28, 2016, 11:00­3:00 EST (GMT­4)

Cost: $249 per person

Copyright © 2016 TenStep, Inc.Follow us on:

   

 

This message was sent to [email protected] from:

Danielle Smallwood, TenStep | [email protected] | Tom Mochal | 2363 St Davids Square | Kennesaw, GA 30152

Unsubscribe

Khaled Dahleez <[email protected]>

Two Ways to Track Requirements Through the Project Phases 1 message

Danielle Smallwood, TenStep <[email protected]> Wed, Jan 4, 2017 at 5:35 PMReply­To: [email protected][email protected]

 

This weekly "tips" email currently has over 100,000 readers. Please click here if you wish to unsubscribe

Free Industry White Papers

 Click here for moreinformation and to see what is

available for free.

Use Traceability to Ensure AllRequirements are Met

Traceability refers to the ability to trace, or track,requirements throughout the lifecycle and into thefinal solution. Tracking requirements through theproject ensures that all requirements are built intothe design, all requirements are built into thesolution, all requirements are tested and allrequirements are implemented in the final solution.This is part of a structured lifecycle process.

Use a Traceability Matrix

The easiest way to create a link between yourrequirements and other development elements isby developing a Traceability Matrix. You couldnumber the requirements as "1", "2", "3", etc.However, you might want to build moresophistication into the numbering scheme such as"TAB­001", "TAB­002", "DIS­001", "DIS­002", etc.

The Simple Approach

Tracking requirements can be done in a couplesimple ways. One way, probably the simplest, isto just validate that each requirement is accountedfor in each project phase. For instance, somethinglike the following table might do.

Requirement# Design Construct ImplementTAB­001 X X XTAB­002 X X  

TAB­003 X X 

The "X" in each box validates that each particular requirement was accounted for in each phase.

A Little More Sophisticated

A more sophisticated example is shown below. In this case, the requirements are tracked through each project phaseand the individual components are also identified. 

Requirement# Design Element Construct Component Test CaseTAB­001 D­APR607P C­APR607P T­004­01TAB­002 D­ARX607P C­ARX607P T­004­09, T­004­15

TAB­003 D­APC103D D­APC103E

C­APC103D C­APC103E T­004­22

This tracking requires the team to keep more details as the requirements are proceeding through the lifecycle. However,it may be helpful to understand the details of the initial requirement, the design element, the component that contains thecode for the requirement and the particular test case that ensured that the requirement worked correctly.

The key thing to remember about traceability is that it must be enforced throughout the lifecycle or else it does not work.If the team assigns tracking numbers to the requirements, but the requirements are not tracked in subsequent phases,the whole tracking scheme will break down.

....................................

Requirements traceability is part of the scope change process. Click here to see a full set of scope managementtemplates (and more) at the Template Collective. Buy now and use immediately. 

Copyright © TenStep, Inc.Follow us on:

   

 

This message was sent to [email protected] from:

Danielle Smallwood, TenStep | [email protected] | Tom Mochal | 2363 St Davids Square | Kennesaw, GA 30152

Unsubscribe