RE-O-Poly: Scenario Card GP1.2a Copyright Renel...

1

RE-O-Poly: Scenario Card GP1.1a Copyright Renel Smith

Since the business goals were well defined at the beginning of the project, stakeholders share the same vision and expectations. The project was successfully completed.

Defining the key business objectives at the start of a project ensures that requirements are what the stakeholders want and mitigates missing requirements and scope creep. (Read Ian Alexander’s “ 10 Small Steps to Better Requirements”)

Collect 100 SSP

RE-O-Poly: Scenario Card GP1.1b Copyright Renel Smith

Since the business goals were not defined at the beginning of the project, stakeholders had conflicting vision and expectations. The project was cancelled.

Defining the key business objectives at the start of a project ensures that requirements are what the stakeholders want and mitigates missing requirements and scope creep. (Read Ian Alexander’s “ 10 Small Steps to Better Requirements”)

Lose 100 SSP


Checklists are used for validation and analysis. You successfully negotiated a win-win situation with conflicting stakeholder goals. Conflicts are inevitable. Achieving mutually satisfactory agreements is critical for building trust and managing expectations. Win-Win is a technique that seeks to keep all parties happy. • The alternatives don’t work • Avoids costly rework due to disenfranchised stakeholders • Builds trust and manages expectations • Helps stakeholders adapt to change and buy into the project Read Barry Boehm “ A stakeholder win-win approach to software engineering education”

Collect 100 SSP


Since the business goals were not defined at the beginning of the project, stakeholders had conflicting vision and expectations.

Conflicts are inevitable. Achieving mutually satisfactory agreements is critical for building trust and managing expectations. Win-Win is a technique that seeks to keep all parties happy. • The alternatives don’t work • Avoids costly rework due to disenfranchised stakeholders • Builds trust and manages expectations • Helps stakeholders adapt to change and buy into the project Read Barry Boehm “ A stakeholder win-win approach to software engineering education”

Lose 100 SSP RE-O-Poly: Scenario Card GP2.1a Copyright Renel Smith You consulted all the essential stakeholders during the Elicitation phase of your project so all their requirements are represented. Tools such as an Ian Alexander’s Onion diagram allow you to easily identify stakeholder

categories. easyweb.easynet.co.uk/~iany Try it!!

Collect 100 SSP

RE-O-Poly: Scenario Card GP2.1b Copyright Renel Smith You failed to consult all essential stakeholders during the Elicitation phase, so all requirements are not represented. Tools such as an Ian Alexander’s Onion diagram allow you to easily identify stakeholder

categories. easyweb.easynet.co.uk/~iany Try it!!

Lose 100 SSP


You included all the essential stakeholders during the Elicitation phase of your project. Everyone is buying in. The requirements engineer needs to bridges multiple stakeholders. Look for the attached organizational/Project roles. [see Wiegers]

Collect 100 SSP


You did not include all essential stakeholders in the project’s Elicitation phase. Essential project requirements were missed. The requirements engineer needs to bridges multiple stakeholders. Look for the attached organizational/Project roles. [see Wiegers]

Lose 100 SSP

2

RE-O-Poly: Scenario Card GP3.1a Copyright Renel Smith Requirements were described clearly and consistently. The set of requirements was easy to check through.

Recommendation for constructing requirements sentence:

The [Subject/Noun] shall [verb] at/when/during [object/quantity] [adverb] [condition/object].

Ex: All users must use MS Word when writing project reports. See Alexander and Stevens’ Writing Better Requirements to learn more.

Collect 100 SSP


Requirements were described poorly. The development and test teams could not easily generate their documents. Recommendation for constructing requirements sentence: The [Subject/Noun] shall [verb] at/when/during [object/quantity] [adverb] [condition/object]. Ex: All users must use MS Word when writing project reports. See Alexander and Stevens’ Writing Better Requirements to learn more.

Lose 100 SSP


Your customer was able to follow the requirements, was able to spot any problems, and knows what to expect.

Requirements must be consistent with each other. They should not contradict, conflict or disrupt other requirements. It is not possible to satisfy conflicting requirements. Your best way to spot this is by writing requirements by using a repeatable format in an atomic manner. See Alexander and Stevens’ Writing Better Requirements to learn more.

Collect 100 SSP


Your customer couldn’t follow the requirements and missed many problems with the design.

Requirements must be consistent with each other. They should not contradict, conflict or disrupt other requirements. It is not possible to satisfy conflicting requirements. Your best way to spot this is by writing requirements by using a repeatable format in an atomic manner. See Alexander and Stevens’ Writing Better Requirements to learn more.

Lose 100 SSP


Since you planned for change, you have a process in place to address customer change requests.

Identified problem

Revised requirements

Problem analysis and change specification

Change analysis and costing

Change implementation

Example of a simple Change Control process (assumes change was approved).

(http://www.processimpact.com/process_assets/goodies_disk.html)

Collect 100 SSP


Since your requirements document was not baselined, bad changes were introduced that cannot be easily identified and reversed.

Identified problem

Revised requirements

Problem analysis and change specification

Change analysis and costing

Change implementation

Example of a simple Change Control process (assumes change was approved).


Lose 100 SSP RE-O-Poly: Scenario Card GP4.2a Copyright Renel Smith Since your requirements document was baselined, errors introduced in later versions could be rolled back. Versioning helps ensure that documents are easy to change and maintain. (http://www.processimpact.com/process_assets/goodies_disk.html)

Collect 100 SSP

RE-O-Poly: Scenario Card GP4.2b Copyright Renel Smith Since your requirements document was not baselined, bad changes were introduced and cannot be easily identified. Versioning helps ensure that documents are easy to change and maintain. (http://www.processimpact.com/process_assets/goodies_disk.html)

Lose 100 SSP

3


Requirements were maintained in an alphanumerical list; hence it was easy to link each requirement to a source and a design component.

Labeling each requirement with a unique identifier (e.g., R1, R2, R3, …) helps with traceability and change management.

See Sommerville and Sawyer's "Requirements Engineering Good Practice Guide (REGPG)" to learn more.

Collect 100 SSP


Requirements were not maintained in a alphanumerical list; hence it was difficult to link each requirement to a source or a design component.



Lose 100 SSP


Since every requirement is uniquely identified and managed in a tool, you know which requirements are stable and which are volatile. Labeling each requirement with a unique identifier (e.g., R1, R2, R3, …) helps with traceability and change management.


Collect 100 SSP


Since your requirements were not uniquely identified or managed in a tool, your requirements remained volatile and unstable.



Lose 100 SSP


You have successfully prioritized requirements to work on in iteration 1. The work can proceed. Triage is a technique used to prune important requirements. To learn more please see Al Davis’s Just Enough Requirements.

Collect 100 SSP

RE-O-Poly: Scenario Card GP6.1a Copyright Renel Smith You have no idea which requirements are important. You cannot proceed with development. Triage is a technique used to prune important requirements. To learn more please see Al Davis’s Just Enough Requirements.

Lose 100 SSP


Your customer has changed the scope of the project, but you were able to incorporate the requested change without impacting the project’s delivery date. The most glaring symptom of unmanageable change management on projects is not defining a process for dealing with requirements changes. The following are good practices: • Define a practical change control process for your project (see GP4). •Supplement the process with a problem or issue tracking tool. •Set up a change control board (CCB) to consider proposed changes at regular intervals and make binding decisions to accept or reject them.


Collect 100 SSP

RE-O-Poly: Scenario Card GP6.2b Copyright Renel Smith Your customer has changed the scope of the project and not provided any additional resources. The most glaring symptom of unmanageable change management on projects is not defining a process for dealing with requirements changes. The following are good practices: • Define a practical change control process for your project (see GP4). •Supplement the process with a problem or issue tracking tool. •Set up a change control board (CCB) to consider proposed changes at regular intervals and make binding decisions to accept or reject them.


Lose 100 SSP

4


You used Volere cards to capture and express properties of requirements; your project is now ahead of schedule. (see www.volere.co.uk)

Volere templates from The Atlantic Systems Guild offer a way to document requirements consistently. They also promote the use of a unique identifier for requirements.

Collect 100 SSP


You did not use Volere cards to capture requirements; your project is behind schedule. (see www.volere.co.uk)

Volere templates from The Atlantic Systems Guild offer a way to document requirements consistently. They also promote the use of a unique identifier for requirements.

Lose 100 SSP RE-O-Poly: Scenario Card GP7.2a Copyright Renel Smith

You adapted templates from experts instead of creating your own. This gives you more time for developing the content. The following is a list of templates that can be adapted: • Vision and Scope Document Template • Use Case Template • Software Requirements Specification Template • Template for Change Control Board Charter • Project Management Plan Template • Project Status Report Template • Request for Proposal Template


Collect 100 SSP


Since you chose to create your own templates rather than adapting those created by experts, the project is behind schedule. The following is a list of templates that can be adapted: • Vision and Scope Document Template • Use Case Template • Software Requirements Specification Template • Template for Change Control Board Charter • Project Management Plan Template • Project Status Report Template • Request for Proposal Template


Lose 100 SSP


Your requirements were easy to understand because you used precise and unambiguous language. The following words should be avoided in requirements documents because they are imprecise. most minimum/mal must nearly necessary needed normal or possible/bly practicable provide quality readily relevant safe/ly same should suitable support target typical up to user friendly whether will with worse and but

Collect 100 SSP


Your requirements were ambiguous and hard to understand. The following words should be avoided in requirements documents because they are imprecise. most minimum/mal must nearly necessary needed normal or possible/bly practicable provide quality readily relevant safe/ly same should suitable support target typical up to user friendly whether will with worse and but

Lose 100 SSP RE-O-Poly: Scenario Card GP8.2a Copyright Renel Smith

Your customer actually read your requirements and understood them. He/She is happy with the quality of your documentation. The quality of your written requirements can be improved by using the following techniques: • Include a glossary for any domain terms • Maintain an adequate level of details with

requirements • Avoid notations foreign to your customers • Avoid technical details

Collect 100 SSP


Your customer had a hard time reading and understanding your requirements. He/She is not happy with the quality of your documentation. The quality of your written requirements can be improved by using the following techniques: • Include a glossary for any domain terms • Maintain an adequate level of details with

requirements • Avoid notations foreign to your customers • Avoid technical details

Lose 100 SSP

5

RE-O-Poly: Scenario Card GP9.1a Copyright Renel Smith Your project took the time to inspect requirements despite time constraints. As a result, problems were eliminated and the customer was happy with the final product. Inspection simply means walking through and discussing every requirement one by one with a group of stakeholders to make sure it is clear, acceptable, sufficiently stable, and understood to support system/software development. Inspections identify defects and save money!

Collect 100 SSP

RE-O-Poly: Scenario Card GP9.1b Copyright Renel Smith Your project skipped the inspection and validation of the user requirements due to time constraints, As a result, errors were missed in the requirements and resulting systems. Inspection simply means walking through and discussing every requirement one by one with a group of stakeholders to make sure it is clear, acceptable, sufficiently stable, and understood to support system/software development. Inspections identify defects and save money!

Lose 100 SSP

RE-O-Poly: Scenario Card GP9.2a Copyright Renel Smith Since the whole team reviewed the requirements document, many of the problems were found and corrected, The team saved a lot of money by minimizing rework. Inspection simply means walking through and discussing every requirement one by one with a group of stakeholders to make sure it is clear, acceptable, sufficiently stable, and understood to support system/software development. Inspections identify defects and save money!

Collect 100 SSP

RE-O-Poly: Scenario Card GP9.2b Copyright Renel Smith Since the whole team failed to review the requirements document, many of the problems were not found and corrected, The team incurred a lot of additional expenses related to rework. Inspection simply means walking through and discussing every requirement one by one with a group of stakeholders to make sure it is clear, acceptable, sufficiently stable, and understood to support system/software development. Inspections identify defects and save money!

Lose 100 SSP

RE-O-Poly: Scenario Card GP10.1a Copyright Renel Smith Since your requirements document is of high quality, you passed your audit. Requirements Documentation should be:

• Verifiable • Attainable • Complete and Concise • Unambiguous and Unique • Managed • Traceable

See Alan Davis’s Just Enough Requirements to learn more. Collect 100 SSP

RE-O-Poly: Scenario Card GP10.1a Copyright Renel Smith Your documentation contained many unverifiable and unattainable requirements. It will need to be revised. Requirements Documentation should be:

• Verifiable • Attainable • Complete and Concise • Unambiguous and Unique • Managed • Traceable

See Alan Davis’s Just Enough Requirements to learn more. Lose 100 SSP


You used several elicitation techniques to ensure you captured the right requirements. Checklist of Requirements Elicitation Techniques: Interviews Workshops Brainstorming Prototyping Storyboarding Observation Questionnaires Business Modeling Reverse Engineering (See Maiden & Rugg "ACRE: Selecting methods for requirements acquisition" to learn more)

Collect 100 SSP


You relied on one elicitation technique to capture requirements. Since that technique was inappropriate for gathering tacit knowledge, your requirements are incomplete. Checklist of Requirements Elicitation Techniques: Interviews Workshops Brainstorming Prototyping Storyboarding Observation Questionnaires Business Modeling Reverse Engineering (See Maiden & Rugg "ACRE: Selecting methods for requirements acquisition" to learn more)

Lose 100 SSP

6

RE-O-Poly: Task Card – Goals

Goals are intentions that a stakeholder has for a development project.

Provide the main business goal for the project in front of you.

100 SSP

Copyright Renel Smith | GP1.1T| Pace DPS 2009

RE-O-Poly: Task Card - Goals

Goals are intentions that a stakeholder has for a development project.

Provide a reason why it is essential to achieve a Win-Win situation when reconciling conflicting goals.

100 SSP Copyright Renel Smith | GP1.2T| Pace DPS 2009

RE-O-Poly: Task Card - Stakeholders

Stakeholder is anyone who gains or loses something as a result of a project.

Provide 2 examples of techniques used to identify stakeholders.

100 SSP


RE-O-Poly: Task Card Stakeholders

Stakeholder is anyone who gains or loses something as a result of a project. Identify 2 key stakeholders for the project in front of you.

100 SSP


RE-O-Poly: Task Card - Structure

Use a standard structure in requirements documents.

Describe a well-written Sentence Structure for capturing a requirement.

100 SSP


RE-O-Poly: Task Card - Structure

Use a standard structure in requirements documents.

Give a reason why it is essential to have consistently written requirements on a project.

100 SSP

Copyright Renel Smith | GP3.2T| Pace DPS 2009 RE-O-Poly: Task Card -Versioning

Versioning makes a document easy to change.

What sequence of events would you include in a requirements change control process?


RE-O-Poly: Task Card - Versioning

Versioning makes a document easy to change.

Give one good reason why a versioning system should be used for managing your requirements document.

100 SSP


7

RE-O-Poly: Task Card - Identifiers Identifiers uniquely identify each requirement.

Give an example of why you should use an Identification system to capture requirements.

100 SSP


RE-O-Poly: Task Card - Identifiers

Identifiers uniquely identify each requirement.

If you want to use a Requirements management tool, how would you uniquely identify the requirements in it?

100 SSP


RE-O-Poly: Task Card – Policy

Use policies for requirements management and conflict resolution.

What kind of scheme could you use to prototype requirements?


RE-O-Poly: Task Card - Policy

Use policies for requirements management and conflict resolution.

Describe a policy for managing requirement changes requested by the customer.


RE-O-Poly: Task Card - Templates

Use standard templates for representing individual requirements.

Provide 3 of the elements you would expect to find in a requirements template that can be used in a project.


RE-O-Poly: Task Card - Templates

Use standard templates for representing individual requirements.

Provide 2 examples of what things you would expect to be in a requirements document.


RE-O-Poly: Task Card - Language

Use language simply, consistently and concisely

Give 3 examples of words that should not be used in a requirements statement.


RE-O-Poly: Task Card - Language

Use language simply, consistently and concisely Give a reason why it is necessary to use a glossary with a requirements document.


8

RE-O-Poly: Task Card - Inspection

Organize formal requirements inspections and acceptance.

What exactly is a requirements

inspection?

100 SSP


RE-O-Poly: Task Card - Inspection

Organize formal requirements inspections and acceptance.

What is the added value of a peer review over individual requirements

review?


RE-O-Poly: Task Card - Checklist

Checklists are used for validation and analysis.

Give 2 examples of where checklists can be used in a requirements project?

100 SSP


RE-O-Poly: Task Card - Checklist


Give 3 characteristics of a quality requirements document.

100 SSP


RE-O-Poly: Task Card - General

Describe the core RE activities?

100 SSP

Copyright Renel Smith | GPG.1T| Pace DPS 2009


Give 2 reasons why most projects fail.

100 SSP Copyright Renel Smith | GPG.2T| Pace DPS 2009


Give 3 characteristics of good requirements.

100 SSP

Copyright Renel Smith | GPG.3T| Pace DPS 2009


Use language simply, consistently and concisely Give an example of a tool used to capture and uniquely identify requirements.

100 SSP Copyright Renel Smith | GPG.4T| Pace DPS 2009

9

RE-O-Poly: Scenario Wild Card

Requirements are ambiguous -- miss a turn to rewrite them.

Copyright Renel Smith | GP1W| Pace DPS 2009


You effectively used a tool to enforce a process.

Receive 100 SSP Copyright Renel Smith | GP2W| Pace DPS 2009



Requirements scope creep -- return to start of this iteration. Do not pass START and do not collect 200 SSP.

Copyright Renel Smith | GP3W | Pace DPS 2009


Because you finished early, go to the next iteration. Advance to START.



Your requirements were done poorly!

Go directly to RE training (Roll a double to get off training or pay 50 SSP)



Get out of RE training FREE. Copyright Renel Smith | GP6W | Pace DPS 2009


You wasted time on a tool thinking it would solve problems. It didn’t.

Lose 50 SSP



Use of unique IDs helped track changes -- roll again.


10


You spent so little time analyzing the problem that you built the wrong system.

Lost 100 SSP


C i ht R l S ith | GP9W | P DPS 2009


You successfully adopted Change Management tools to track and control changes.

Collect 100 SSP Copyright Renel Smith | GP10W | Pace DPS 2009

11

Descriptions of the Front of the Project Cards

Basic Project: Calculate Customer Interest

Project Objective: Create a simple system for calculating customer’s interest payment within one month using existing bank resources with your department. No special hardware or software will be required.

Average Project: Determine and Print Customer Statements

Project Objective: Determine and print monthly customer statements. The project must be completed within six months using existing bank resources across multiple organizations.

Complex Project: Build a real-time exchange systems

Project Objective: Create a simple system for calculating customer’s interest payment within one year using existing bank resources and several outside agency. Development will require servers and associated network hardware and software upgrades. This project is important to the highest level of the organization.

12

Questions on the Back of the Project Cards Provide the main business goal for this project. Provide a reason why it is essential to achieve a Win-Win situation for stakeholders on this project. Provide an example of a requirement template that you could use for this project? Provide 2 examples of techniques you would use to identify stakeholders for this project. Identify 2 key stakeholders for this project. Provide an example of a stakeholder goal for this project (not used before). Describe a well-written Sentence Structure for capturing requirements for this project. Write out a hypothetical requirement for this project, using a ‘good’ structure. Give two examples of good practices to avoid inadequate change process for this project. What should you put on a requirements document to help you understand changes later? Give one good reason why a versioning system should be used for managing your requirements document on this project Do you need to establish a version control system for this project? If so, what would be the main benefit? Give an example of an Identification system you could use to capture requirements on this project. If you want to use a requirements management tool for this project, how would you uniquely identify the requirements in it? Why should you have a versioning control system for this project? Describe a policy for managing requirement changes requested by the customer on this project. What kind of scheme could you use to prototype requirements on this project? What would you use (tool/approach) to handle requests from the customer to change requirements on this project? Provide 3 of the elements you would expect to find in a requirements template that can be used in a project. Provide 2 examples of what things you would expect to be in a requirements document. Provide 2 examples of what things you would expect to be in a change management template for this project. Give 3 examples of words that should not be used in any requirements statement for this project. Give a reason why it is necessary to provide a glossary for this project. Suggest 2 domain terms for this project that may require more detailed explanation on meaning.

13

Why might you run a requirement inspection for this project? What would be the added value of running a peer review over individual requirements review on this project? How and when would you run a requirement inspection on this project? Give 2 examples of where checklists can be used on this project? Give 3 characteristics of a quality requirements document that can be used for this project. Provide 2 examples of things you would expect to find in a change control checklist for this project.

RE-O-Poly: Scenario Card GP1.2a Copyright Renel...

Documents

Transcript of RE-O-Poly: Scenario Card GP1.2a Copyright Renel...