REQUIREMENT WORKSHOP

1. REQUIREMENT WORKSHOP Alex Rowe Jifei Sun William Houghton

2. Software Requirements • Requirements form a set of statements that describe the user’s needs and desires. • In developing a software system, these requirements must be clearly and fully understood by the software engineers who develop the software system.

3. Functional Requirements • Input formats • Sorting • Special cases, boundaries, and error conditions.

4. Nonfunctional Requirements • Performance requirements • Real-time requirements • Modifiability requirements

5. Project Failures • Top 3 reasons of failure for project • Lack of input • Incomplete requirements and specifications • Changingrequirementsand specifications

6. Software Product Failures • Requirement errors: 12.50% • An error introduced during the requirements phase may propagate into design and coding. • Fixing a requirements error is generally more expensive than fixing a code error. • Even though the percentage of errors originated from the requirements phase is only 12.50%, the cost of fixing those problems is usually most expensive.

7. Good Requirements • Unitary (Cohesive) • Complete • Consistent • Non-Conjugated (Atomic) • Traceable • Current • Feasible • Unambiguous • Mandatory • Verifiable

8. Major steps of requirements engineering • Elicitation • Documentation and definition • Specification • Prototyping • Analysis • Review and validation • Agreement and acceptance

9. Requirement Workshop(Preparation) • To prepare for a Requirement Workshop you need to gather a group of stakeholders • Once you gather the stakeholders together you need to lay down the guidelines or rules that will be applied for the meeting • One thing to remember is that the Requirement Workshop is not an elicitation technique within itself and requires other techniques to be successful

10. Requirement Workshop(Preparation cont.) • When running the Requirement Workshop you should be prepared: • to know what the stakeholders want even when they don't know it • to know what the stakeholders want even when they don't know how to say it • to know what the stakeholders want even when they think they know what they want, but don't

11. Running a Requirements Workshop In a requirements workshop, a group of people share a common goal. They agree to join together to work toward that goal.

12. The Task Group The workshop participants are called a task group. Task groups consist of people with multiple skill sets and knowledge to create the work product. They are composed of business profesionals and IT experts, led by a facilitator who runs the workshop. A scribe is also present. The scribe documents all important points discussed as the project proceeds. The facilitator or scribe do not act as an expert on the product. Instead, they are to keep the group on a steady track.

13. Leading the Workshop Give a thorough introduction. Define a clear purpose and scope. Discuss results and long term plans. Allow any and all questions. Ideas and principles mean many different things to each person in the room. Designate a scribe. Every statement and requirement should have a label with who came up with it. Classify requirement levels. Must-have, nice-to-have, suggestion, not-needed, etc.