Reading...
Play button
Play button
Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
23 Cards in this Set
- Front
- Back
|
Learning outcomes
|
At the end of this module, Students will be able
to : -Describe the importance of reusing requirements -Discuss the importance of Lessons Learned -Run a Kaleidoscope Brainstorming session -Create a communications plan |
|
|
Requirements reuse
|
-Involves reusing requirements across
projects -Not currently a typical business practice for requirements -Standard practice in software development -“assets” of the company |
|
|
Requirement reuse per project
|
|
|
|
What are Four factors impacting reuse benefits?
|
Four factors impacting reuse benefits:
1)Requirements maintenance cost 2) Similarity of applications 3) Existing requirements quality 4) Existing requirements structure and the level of abstraction |
|
|
Requirements reuse across Traditional RE, Use-case-driven and agile:
|
|
|
|
What are some other aspects of requirements reuse?
|
Create standards for how and when
requirements may be maintained for reused Identify requirements that are candidates for long term use Central repository needed |
|
|
What is a lessons learned document?
|
Documented as discovered
Session conducted at the end of the project to determined – What went well – What could have been improved |
|
|
Lessons Learned – Review Session
|
BA activities and deliverables
Final product -Customer satisfaction -Quality of product -Variance from business and project objectives BA Process Variances Corrective actions |
|
|
What are some questions regarding lessons learned?
|
Did the product meet requirements?
Was the customer satisfied? Why/why not? Was BA budgets/schedules met? Were risks identified and mitigated? Did the BA process work? What could be done to improve the BA processes? |
|
|
More questions about lessons learned.
|
What bottlenecks, barriers or hurdles were
experienced? What changes would assist in improving KPIS’s of future initiatives and projects? What “best practices” emerged? |
|
|
What are some aspects of the lessons learned process?
|
During your discussions:
■Be positive ■Do not place blame! ■Focus on successes as well as failures ■Indicate which strategies contributed to success ■Indicate which improvement strategies would have the greatest impact |
|
|
What are some aspects of lessons learned documentation?
|
The Lesson Learned Knowledge Base contains
historical information from previous projects. It is part of the organizational project assets and provides a valuable source of information to be used by similar projects and initiatives in the future. All lessons learned and other historical information need to be transferred to this knowledge/database in order to provide one centralized repository for ease of use. |
|
|
Documentation con't
|
This should also include information on
issues and risks as well as techniques that worked well which can be applied to future projects. Most lessons learned knowledge/databases contain large amounts of information, so it is important that there is a system for cataloging this information. |
|
|
Continous improvement initiative for lessons learned:
|
|
|
|
What are some aspects of brainstorming?
|
-When you have no idea, or too many ideas
-Most useful early on, when terrain is uncertain, or when you have little experience -When innovation is important. -Ground rules |
|
|
Who participates in brainstorming?
|
Developers, domain experts, implementation
experts, sponsor, other stakeholders Companies will bring in special-purpose “ideas-people” who lead or attend these meetings, but may not participate beyond this stage |
|
|
What are some roles within brainstorming?
|
First, must designate two (different!) people for special roles:
1) Scribe - Role is to write down all ideas. May also contribute.May ask clarifying questions during first phase, but not critical questions 2) Moderator/leader - Two schools of thought on this: – Traffic cop - enforces “rules of order”, but doesn’t throw his/her weight around otherwise – Agent provocateur - Assumes more of a leadership role, comes prepared with wild ideas and throws them out as discussion wanes. May also explicitly look for variations and combinations of other suggestions. Not a “philosopher-king”. Also acts as traffic cop. |
|
|
What are some aspects of Part 1 of brainstorming, what is it called?
|
Part I - The Storm
-Goal is to generate as many ideas as possible -Quantity, not quality, is goal at this stage -Look to combine or vary ideas already suggested -No criticism or debate is permitted. Don’t want to inhibit participants. -Participants understand nothing they say will be held against them later on. -Scribe write down all ideas where all can see e.g., whiteboard, paper taped to wall -Wild is good. Feel free to be gloriously wrong Participants should NOT self-censor or spend too much time wondering if an idea is practical. Just shout it out. Original list does not get circulated outside of the meeting |
|
|
What are aspects of the second part, The calm?
|
Part II - The Calm
Go over the list. Explain ideas more carefully. Categorize into “maybe” and “no” by pre-agreed consensus method – informal consensus, 50% + 1 vs. “clear majority”, Dutch auction, who has vetoes Be careful about time. – Meetings (esp. if creative or technical in nature) tend to lose focus after 90 to 120 minutes. Take breaks or reconvene later Review, consolidate, combine, clarify, expand Rank the list by priority somehow; choose a winner Look out for: – Haggling over details – Hurt feelings – Time limits |
|
|
What is Kaleidoscope brainstorming?
|
1. Initial ideas generation brainstorming
2. Silent brainstorming session a) Identify what you THINK the person to your right would brainstorm b) Identify what you THINK the person to your left would brainstorm 3. In turn, discuss the ideas you attribute to your neighbour 4. Brainstorm again – with this new information |
|
|
What is requirement communication planning?
|
Requirement Communication is Defined as
-The collection of activities for expressing the output of the requirements analysis and documentation -It is an ongoing, iterative activity conducted in parallel with requirements gathering and analysis Rationale -Stakeholders have to be aware of the status and content of the requirements analysis and documentation -Effect is to push the Business Analyst even more into the forefront -The BA serves as the primary spokesperson for communicating up and out of their respective organizations |
|
|
What do you need to determine in requirements communication planning?
|
-Determine who your stakeholders are
-Determine what their informational needs are with regards to your project -Determine which means of communication are appropriate eg. Email, reports, phone call -Determine the frequency of communication -Determine the level of detail of the communication -Confirm with the stakeholder that you have been/are meeting their needs |
|
|
What are some considerations for a business analysis communication plan?
|
1. What needs to be communicated
2. What is the appropriate delivery method 3. Who is the appropriate audience 4. When the communication should occur. 5. Time and resource availability constraints. 6. Physical location/time zone of the stakeholders. 7. Communication approach for the stakeholder. 8. What types of communications will be required (e.g. status, anomalies, issues and their resolution, risks, meeting results, action items, etc.) 9. How best to communicate requirements conclusions/packages, including authority level (signoff authority, veto authority, or review only). |
