Gathering The Requirements - Ch. 9 Flashcards
What has been the most common reasons for IS project failures over the last 30 years?
- Over 80% of errors are introduced at the requirements analysis stage
- Only 10% are introduced at the development stage
- Most of the project time is allocated to development and testing
- Less than 12% of the project time is allocated to the requirements analysis phase
- There is poor alignment of the developed system to the business strategy and objectives
- There is poor requirements management
The cost of correcting errors in requirements increases dramatically the later they are uncovered during the development lifecycle.
Name some typical requirements problems.
- Inability of users to articulate what they want
- lack of televant to project objectives (TERMS OF REFERENCE)
- OSCAR
- Objectives
- Scope
- Constraints
- Authority
- Resources
- lack of clarity in wording
- ambiguity
- duplciation
- conflicting requirements
- no clear measures (have they been achieved?)
- requirements assuming a soluton rather than stating what is to be delivered by the system
- uncertainty amngst business users about what they need
- inconsistent levels of detail
- business users omitting to identify requirements
- business users and analysts taking certain knowledge for granted and failing to ensure there is common understanding
- stakeholder perspectives not being recognised (DUCKRABBIT) http://www.google.co.uk/imgres?q=duckrabbit&hl=en&sa=X&tbo=d&biw=1920&bih=892&tbm=isch&tbnid=93kuwH31HEO5DM:&imgrefurl=http://en.wikipedia.org/wiki/File:Duck-Rabbit_illusion.jpg&docid=upcmllRNCJ3B0M&imgurl=http://upload.wikimedia.org/wikipedia/commons/4/45/Duck-Rabbit_illusion.jpg&w=519&h=350&ei=TRSyUI89pOPhBLLlgdAJ&zoom=1&iact=hc&vpx=2&vpy=124&dur=3802&hovh=184&hovw=273&tx=158&ty=208&sig=114806300119273924137&page=1&tbnh=140&tbnw=210&start=0&ndsp=47&ved=1t:429,r:0,s:0,i:85
What is the Requirements Engineering Process
Requirements Elicitation (loop til complete)
Requirements Analysis (loop til complete)
Requirements Validation
Requirements Documentation
Requirements Management
It is the approach by which we ensure the process of understanding and documenting the business requirements is rigorous and ensures the traceability of each requirements.
Stages are: elicitation, analysis, validation, documentation and management. This ensures the organisation places sufficient emphasis on defining requirements to ensure implemented solutions meet business stakeholders needs, allowing them to perform their jobs effectively.
Requirements engineering is an approach that ensures we can deliver solutions and truly meet business needs.
What is Requirements Elicitation?
Gathering information and requirements from business stakeholders.
What is Requirements Analysis?
GATEKEEPER ROLE ensuring only those requirements that pass scrutiny will be entered into the Requirements Catalogue.
Examining requirements gathered during elicitation in order to identify those that overlap, are in conflict or are duplicates.
Scrutinising requirements to ensure they are well formed (clear and unambigious).
The analysis will highlight any areas for further elicitation.
External stakeholders reviewing requirements and agreeing sign off (requirements catalogue).
What is Requirements Documentation?
The development of a well-organised requirements document.
What is Requirements Management?
Managing changes to requirements.
Recording, analysing and acting on changes and ensuring that every requirement is fully traceable from initial recording to sign-off during UAT.
What are CASE tools?
Computer Aided Software Engineering tools.
Who are the main actors involved in the requirements process?
- Business Representatives
- Project Team
What roles would business representatives play during the requirements process?
Project Sponsor
- agree PID
- deliver spefic, agreed business benefits as predicted in business case
- make funds and resources available for the project
- accept deliverables at project end
- approve and sign off requirements
- rule on any conflicting requirements
Domain Expert
- high level advice on requirements when they:
- cover more than one business area
- relate to redesigned process
- organisation wishes to introduce new product not yet fully understood
- organisation wishes to adopt latest industry best practice
Business Users
- Describe current procedures and documentation
- Highlight any difficulties currently exeperienced
- Identify new requirements for the system
- Assist in defining detailed requirements by providing specific, clear inforamtion.
- Assist with the definition of Non-Functional requirements that apply to their tasks.
- Assist with the definition of roles within the system.
Developer
- Checks technical feasibility
- Helps BA appeciate requirement implications
- Produces prototypes to assist in confirmation of requirements
What are the pros and cons associated with using an external domain expert/consultant
Pros
Fresh views and industry insights
Draw on best practice used elsewhere in the industry
Cons
May not understand how the company works or its culture (solution may be inappropriate)
May be unaware of political undercurrents (affecting the projects success or failure)
May be regarded as outsiders (resented by internal workers)
What roles would the project team play during the requirements process?
Project Manager
- Ensures the business requirements are met and satisfies the business imperaties that drive the project. Reports to Project Sponsor.
- Breaks the project down into identifiable, measurable pieces of work with clear deliverables
- Allocates work
- Schedules tasks with start and end times, recognising dependencies between tasks
- Monitors progress and any likely slippage
- Taskes corrective action on slippage or risk on non-completion of any task
***Many companies allocate the Project Manager role to the BA, but this is problematic as the two roles call for different aptitudes, priorities and skills. There can be conflicting priorities and interests needing reconilitation, which will be problematic if one individual is carrying out both roles.***
How has Requirements Elicitation changed
Used to be known as requirements capture.
It used to be concerned with developing systems to perform tasks being carried out by people.
Nowadays it is imperative for systems to aid the organisation in gaining a competitive advantage, support new business processes or support a business process re-engineering process.
This means the business is more likely to be unclear about what they need the system to provide.
The onus to identify requirements used to be on the business user, whereas requirements elicitation is a proactive approach to understanding requirements and invovles drawing these out from the users and helping them to visualise the possibilities and therefore articulate their requirements.
Requirements emerge as a result of the interaction between analyst and user, and take into account the need for different techniques to elicit TACIT and EXPLICIT information.
What is tacit information? Give me some examples of how this type of information shows up during the elicitation phase.
Information that is hard to articular or explain and is ‘just known’.
- skills: driving, tying shoelaces
- taken-for-granted information or “not worth metnioning” information: “of course the customer will want a booking number sent to them by email”!!!
- Front story/back story (SWAN): framing a description or current working practices or a workplace in order to give a view that appears more positive than is actually the case (swan gliding peacfully across the smooth suface of a lake (front story) whereas its feet are paddling frantically to sustain the gentle momentum (back story).
- Conceptualising requirements: where there is a lack of expertise or knowledge on a new business system in the business it is difficult for stakeholders to imagine what they require the solution to offer. (SCENARIOS AND VISUAL REPRESENATION HELPS TO ARTICULATE THEIR REQUIREMENTS)
- Common Language Assumptions - “Your finger, you fool!” (FINGER): 17th Century explorer asked a native explorer name of mountain by pointing to it and saying what is that. Did not recognise pointing gesture and said your finger.
- Intuitive Undestanding (considerable experience): logic ends and intuition takes over as users have considerable experience (Medical Diagnosis).
- Organisational Tacit Knowledge:
- Norms of behaviour and communication
- Organisational culture
- Communities of practice (groups of workers)
What is explicit knowledge? Give me some examples.
Task definitions
Job descriptions
Targets, Volumes and Frequencies
Procedures
Style Guides
Processes
Knowledge Sharing Repositories
Manuals
Company Reports
