1. Requirements Workshop Techniques for E-Business Projects
Introduction:
Requirements Workshop Techniques for E-Business projects.
The Rational Unified Process is a robust software engineering process. Its main goal is helping you deliver high quality software that meets the needs of the users in a timely and cost-effective manner. Effective requirement gathering, especially on e-business initiatives, has its own set of challenges. This presentation will show you proven techniques that will help you collaborate better with your customer in delivering more complete requirements, a sound architecture, prototypes, and better estimates for construction and transition even if the project is in rescue mode or there is very little time for requirements gathering. While these techniques are best suited for e-business they may be applied effectively to other initiatives with similar success.
Prepared by
Bruce McGinley PMP

2. RUP Best Practices

3. Agenda E-Business Development Overview
Roles, Activities, and Artifacts
The Workshop Process
How to Measure Success

4. Where are We in RUP? The RUP has two dimensions:
The horizontal axis represents time and shows the lifecycle aspects of the process as it unfolds
The vertical axis represents disciplines, which group activities logically by nature.
The first dimension represents the dynamic aspect of the process as it is enacted, and it is expressed in terms of phases, iterations, and milestones.
The second dimension represents the static aspect of the process: how it is described in terms of process components, disciplines, activities, workflows, artifacts, and roles.

5. E-Business Development - Overview
E-Business is about building systems, sometimes called business tools, that automate business processes
Typically the tools are the business and a way to differentiate you from your competitor
Categories – B2B, B2C, C2B, C2C
Many more stakeholders are involved in the development of business tools
Organizations developing e-business solutions consider business modeling as a central part of their projects. They use model-based technologies to develop both rapidly and in a controlled manner. The business and the business tools that support it are regarded as an integrated whole, and delivering the right solution requires a much tighter integration of business process definition and system development than has been needed in the past. Many more stakeholders are involved in the development of the business tools.
An e-business development effort is more than just automating existing processes; it forces some reflection on the nature of the business and the way it is run. Business modeling and system definition are not only of interest for people in the Information Technology department, it is of concern for everyone involved in business development.
The business tools built under the umbrella of e-business development can be categorized as follows: 
Business to business (B2B)—application that automate a supply chain across two companies. 
Business to customer (B2C)—application that provide information to otherwise passive customers, such as distributing news letters. 
Customer to business (C2B)—applications that allow you to order goods over the Internet, such as electronic books stores. 
Customer to customer (C2C)—applications that allow customers to share and exchange information with little information from the service provider, such a auctions. 

6. E-Business Development - Overview
Characteristics in Common with complex IS development
Externally imposed rules and regulations, often of high complexity, such as business rules.
High complexity in data structures.
Customer focus.
Pressed time schedules.
Performance and reliability of the final system is a primary concern. 

7. E-Business Development - Overview
Unique Characteristics
More emphasis on business modeling. 
More emphasis on user-interface design. 
Use of e-business enabling technologies to define the architecture. 
A greater focus on performance testing. 
e-business Technologies
Revolutions in technology lead to new business opportunities and drive changes to business processes. The e-business concept is one of the more illuminating examples of this happening. The primary driving technology in this case is the Internet, but there are also many other technologies needed that are not necessarily specific to e-business but are important components. Such enabling technologies include [CONA99]:
Client/server
Database management
Programming languages, such as HTML, XML, Java
Scripted server pages and servlets, such as Microsoft's Active Server Pages, Java Server Pages
Object communication protocols, such as OMG's Common Object Request Broker Architecture (CORBA), the Java standard Remote Method Invocation (RMI), or Microsoft's Distributed Component Object Model (DCOM)
Components, such as Microsoft's ActiveX/COM
Web applications frameworks, such as IBM's WebSphere or Microsoft's Windows DNA

8. Roles, Activities, & Artifacts
Definitions
Role – An abstract definition of a set of activities performed and artifacts owned.
Activity - A unit of work a role may be asked to perform.
Artifact - A piece of information that is produced, modified, or used by a process, defines an area of responsibility, and is subject to version control.
Scenario - A use-case instance; simply a specific "path" through the possible basic and alternative flows.
An artifact can be a model, a model element, or a document. Artifacts provide the input and output for the activities, and the mechanism by which information is communicated between activities.

9. Customer Roles Roles, Activities, & Artifacts Role Attendance
Participation
Executive Sponsor
Required
Active
Business Partner
Subject Matter Expert
Observer
Optional
Passive
Executive Sponsor
Provide leadership and financial sponsorship of the development initiative.
Responsible for the overall scope and purpose of the initiative
Communicates support and ensures expectations are properly communicated to participants
May kick off the initial session, but does not normally participate unless there are policy issues for which the sponsor is directly responsible
Business Partner
The business manager who has been tasked by the sponsor and given responsibility for successful execution of the business aspects of the initiative
Along with the technical partner, this person is responsible for facilities and scheduling, ensuring the availability of the executive sponsor and the participants for all session activities, and final review of the deliverables
May or may not be a SME or stakeholder participant
Subject Matter Expert
Problem domain experts – those who have a deep understanding of the system or certain aspects of the system
Expected to participate actively and is responsible for the accuracy and completeness of session deliverables
Observer
A neutral party who may observe the session for the purpose of being informed, learning the process, or critiquing the process
This person is not allowed to participate

10. Development Team Roles
Roles, Activities, & Artifacts
Development Team Roles
Role
Attendance
Part.
Artifacts
Facilitator
Required
Active
None
Project Manager
Scribe
Risk list, Software development plan, Schedule, Iteration plan
Requirements Specifier
Software requirements specification, Use cases
UI Designer
Prototypes
Architect
Passive
System architecture, implementation model
Data Analyst
Entity definitions, Data model
Test Manager
Test plan, Review requirements
Observer
Optional
Facilitator
A neutral person who can be forceful in guiding the sessions towards completion
Knowledgeable in both the business and technical aspects of the initiative
Guides the JAD sessions towards production of the deliverables
Uses white boards to draw the Use Case Model, Screen Flow diagrams, and Sequence Diagrams
Final production of the results and distribution is not the responsibility of the facilitator
Project Manager
Has overall responsibility for the project including distribution of the results of the sessions
Captures functional capabilities, business rules, reports
Create work plan and resource estimates
Requirements Specifier
Captures use case model, actor catalog, use case catalog, sequence diagrams, screen flows
User Interface Designer
Captures the storyboards, screen catalog
captures requirements on the user interface, including usability requirements
builds user-interface prototypes
involves other stakeholders of the user interface, such as end-users, in usability reviews and use testing sessions
reviews and provides the appropriate feedback on the final implementation of the user interface, as created by other developers; that is, designers and implementers.
the skills required by a user-interface designer often need to be improved and optimized for the current project and application type, with potentially unique usability requirements, and this requires both time and focus.
the risk of "mixed allegiances" must be delimited; that is, the user-interface designer needs to be influenced more by usability considerations than implementation considerations.
Architect
Creates system architecture, orthogonal view, class diagrams, package descriptions, technical specifications
Data Analyst
Captures system entities, ER diagrams
Test Manager
Tasked with the overall responsibility for the test effort's success

11. Uses Facilitated Sessions
The Workshop Process
Uses Facilitated Sessions
Different from most meetings
Structured in a manner proven to achieve preplanned results
Its structure can be customized to meet specific needs
There are defined roles
A facilitated session is a formal approach for hastening the process of collecting and gaining concurrence on topics under discussion.

12. Supplies in hand prior to the Workshop
The Workshop Process
Supplies in hand prior to the Workshop
Laptops with software for the development team
Local network with printer (and paper)
Easel with self-sticking flip charts
White boards everywhere
Dry erase marker sets
Small sticky notes
Masking tape

13. Wall Areas Reserved The Workshop Process Charts Wall areas reserved
Parking Lot
Action Items
Risks and Issues
Wall areas reserved
Use case model
Screen flow diagrams
Activity diagrams
Sequence diagrams
Functional capabilities
Business rules
Glossary

14. The Workshop Process Ground Rules
Work is time-boxed to four hours so that SMEs can get back to work and designers can document and organize work.
Decisions will be forced as much as possible to get to a system quickly.
Avoid out-of-scope issues, excessive detail and things that developers can work out later.
Architectural artifacts are not normally reviewed with SMEs as they may be confusing to them and waste their valuable time. The architect and the facilitator refine the design during the reconciliation portion of the sessions.
Decisions will be forced as much as possible to get to a system quickly. Typically no decision is much worse than an 80% correct decision. SMEs will prefer to defer way too much but the facilitator must get consensus decisions as items are discussed. You can always change an aspect of the system at a later time if really necessary. The facilitator will manage the time to get the work done on time.

15. The Workshop Process Prepare for the Workshop
Inception milestone reached
Participants identified and scheduled
Meeting room reserved offsite
Projector and other resources reserved for the duration of the workshop
Availability commitments, SME’s participation essential, development team may work long hours
Artifacts and templates ready
Conduct a practice meeting for the development team
Supplies in hand
Inception Phase
is of significance primarily for new development efforts, in which there are significant business and requirements risks which must be addressed before the project can proceed.
Evaluation Criteria [Lifecycle Milestones Objective]
Stakeholder concurrence on scope definition and cost/schedule estimates
Agreement that the right set of requirements have been captured and that there is a shared understanding of these requirements.
Agreement that the cost/schedule estimates, priorities, risks, and development process are appropriate.
All risks have been identified and a mitigation strategy exists for each.
Facilities and other Resources
Reserve the meeting room for the complete time, if possible, as you will want to leave your work on the walls.

16. The Workshop Process Conduct a Planning Session
Introductions, roles and responsibilities, sign in sheet
Process and expectations explained
Define the Use Case Model
No use case relationships
Don’t consolidate use cases until flows are discussed in later sessions
Capture risks, issues, parking lot, action items.
Explain the model
Plan and create agenda for all other sessions

17. The Workshop Process Define a Use Case
Detail the use case by Storyboards, Screen Flow diagrams or Activity diagrams
Always model the primary scenario. Also called the ‘happy path’, ‘happy day’, or basic scenario.
Model alternate scenarios when they:
Are not obvious
Need additional definition
Can be done in the allotted time
Target four hour session
All roles are in attendance and focused together in exploring business needs and in defining the use case detail.
All work is diagrammed on a dry-erase board and adjusted as the needs are discussed.
It is important that the system designers focus on listening and understanding the needs of the system rather than documenting the system during this session so that they will gain as much understanding as possible during the session.
Draw a complete definition of this particular use case. Focus the team’s attention to each of the details being defined here. Don't worry about making it perfect here as the developers will do the wordsmithing and refinement during the reconciliation portion of the session. Concentrate here on getting information from the subject matter experts on WHAT is to be done and WHAT is to be viewed. Define all the detailed information related to a use case.
Note functional capabilities and business rules on the board as they are identified. Use the notation FC... and BR.... to signify the type of requirement and just write it out in as understandable a form as possible.
Lay out complete screen flow diagrams noting all actor interactions. Fill in the detail of each screen as it is discussed. Don't design pretty screens but ensure that complete data content is noted on each screen. To the extent possible, use appropriate controls to aid in visualizing the user experience even though the controls are not final nor arranged optimally. Save screen layouts as pictures so that they can be easily viewed by anyone, whether they have Visio installed or not.
Develop sequence diagrams for back-end processes and any logically complex interaction. These are used mostly for defining processes that have no screen user involvement.

18. The Workshop Process Reconcile the Use Case
Only the development team participates in this session which immediately follows the definition session.
Document the work that was discussed during the previous definition session.
Discuss the information gathered and determine whether there are additional questions to answer gaps in understanding necessary for completion. These questions will be included in the review to follow.
Print the documents and post them on the walls for review.
The details are documented or edited in the best state possible based on the definitions at hand.
All work completed and reconciled before going home each night

19. The Workshop Process Review the Use Case
All participants (including SMEs) review the printed results of the previous session.
The facilitator leads the team around the room to all use cases that are being reviewed.
The screen flows are followed through the entire use case.
Sequence diagrams are followed to ensure that the documentation of the findings are accurate.
Pencil in changes on the wall. If the document does not have room or is not conducive to this, use a Post-It note with the changes described.

20. The Workshop Process Capture Non-Functional requirements
General functionality
Usability
Reliability
Performance
Supportability of the system

21. Create task by resource chart
The Workshop Process
Create Construction Estimates
Create task by resource chart

22. The Workshop Process Review Artifacts with Customer
Get sign-offs where appropriate

23. How to Measure Success Success Criteria
Ensure that the architecture, requirements and plans are stable enough, and the risks sufficiently mitigated to be able to predictably determine the cost and schedule for the completion of the development
Maximize collaboration with the subject matter experts early on in the process resulting in more complete requirements and good project involvement throughout the project lifecycle
Shorten overall project length
Target developing a system that truly meets the immediate business needs
Obtain solid closure on expectations in terms of business requirements, schedules, and costs.
Focus on only what is absolutely necessary
Produce more predictable results
Better estimates

24. Thank You!