Where do you find requirements?

What is a requirement?

• Generally a requirement is something that must be met by a living (or) non-living entity in order to achieve a task (or) document.
• That something can be a condition or capability
• Entities can be related to user(s), system (or) a sub component.
• Achievement or documents are generally problems, goals, objectives, contracts, standards and formal documents.
• They can be descriptions of how an application or component should behave.
• Can also be considered as the required implementations.
• They can be related to system property or attributes – i.e. how well a system does it.
• Sometimes they may be constraints in the development process.
Common types of requirements

1. Business requirements: Describe why we are undertaking a particular project, who will benefit from implementation of this project, what are the business objectives, why to invest money on this particular project.

2. User requirements: Describe what the user will be able to do with the system.
Use cases are functional requirements but when given to developers it does not work all the time, it gives a general idea but often fails to provide enough information as a result more information has to be tracked down in order to build an application.
3. Functional requirements: Describe the specific bits of functionality that developers need to implement.

4. System requirements: Relates to a product comprised of multiple subsystems.

5. Business rules: Usually contain the following:
• Corporate policies
• Industry standards
• Government regulations
• Computational algorithms

6. Quality attributes: Usually include the following:
• Usability
• Portability
• Maintainability
• Quality of service requirements:
o Integrity
o Efficiency
o Robustness
o Performance

7. External interfaces: connections to various interfaces, design and implementation constraints.

Sources/techniques for requirements gathering:

1. Brian storming
2. Document analysis
3. Reverse engineering
4. Focus groups
5. Observation
6. Workshops
7. JAD sessions
8. Interview
9. Prototyping
10. Questionnaire

Explanation:
Brian storming: Is done by a group of people sitting together as a group, all the people start giving their ideas, ideas spark other ideas and eventually it inspires a unique idea that no one else has, that unique idea may be inspired by all the other ideas discussed before.
Does of brain storming:
• Capture everything (i.e. write down everything that any one says) never skip any idea
• Encourage participation
• Ask clarifying questions (i.e. clarify the suggested idea)

Don’ts of brain storming:
• Evaluate anything initially
• Force participation or sequence
• Ask judgemental questions
Once the list of ideas is created the following are to be performed:
• Find like ideas and group them to reduce the list
• Eliminate the non – feasible ideas from the list
• Analyse the remaining ideas and propose them for implementation
Document analysis: Is a means to elicit requirements by studying available documentation on existing and comparable solutions and identifying relevant information.
Document analysis may include analysis of business plans, market studies, contracts, requests for proposal, statements of work, memos, existing guidelines, procedures, guides, competing product literature, published comparative product reviews, problem reports, customer suggestion logs, existing system specifications, standards operating procedures.
Stages of document analysis:
1. Preparation
2. Document review
3. Wrap – up
1. Preparation: Identify the documents relevant to business analysis activity and gather them.
2. Document review: Study the document and extract the relevant information out of them.
3. Wrap – up: Information acquired during review must be validated for authenticity and credibility of the information.
Reverse engineering: Is used to understanding the application in hand by interacting with it directly without any prior experience or knowledge.
Categories of reverse engineering:
Black box: Application in hand is studied without examining its underlying structure.
White box: Application in hand is examined with inner workings of the hidden structure.
Results of reverse engineering:
• An understanding of how a product works more comprehensively than by merely observing it.
• A means to investigate errors and limitations in existing programs and a help in correcting them.
• Details to help make products and systems compatible.
• Details to help evaluate a product and understand its limitations.
• Determining whether someone else has literally copied elements of one’s own technology.
• Documentation of a product whose manufacturer is unresponsive to customer service requests.
• Details to help transform obsolete products.
Focus groups: Instead of polling large number of people with straightforward questions and quantifiable answers, in person interviews are concocted in small groups engaging them in open discussions, it’s a qualitatively technique focused on people preferences and thoughts, rather than providing definite conclusions for business focus groups are used for exploratory research, generating new ideas for products based on deeper understanding on user habits.
How does a focus group work?
First, a group is formed with 6 – 10 participants according to specific criteria that meets a desired objective, during the session participants are asked to respond to various prompts from the group moderator like sharing their opinions on certain product or their emotional reaction.
Although focus groups provide valuable insight they do have limitations such as:
• Simple act of observation (observer interference)
• Social pressure from the rest of the group
• Simply knowing that they’re taking part in a focus group
There are two categories of focus groups:
Homogeneous: Individuals with similar background, perspectives
Heterogeneous: Individuals with diverse backgrounds, perspectives
The moderator should be experienced in facilitating groups. Typical skills include promoting discussions, asking open questions, facilitate interactions between group members, engage all members, keeping session focused, remain neutral, and be adaptable and flexible.

Observation: Is a process of understanding the current legacy system by viewing how user approaches and interacts, user here is generally in often cases a SME, there are two types of observations.
1. Active: In this case the process is observed by taking notes and indulging in a dialogue with the user, the questions are immediate asked even if it disturbs the flow of the SME, BA might also involve in the current process to gain hands on experience.
2. Passive: In this case the BA never interrupts the SME during the flow and notes down all the points to be clarified and poses those question only after the SME ends the flow.
Workshops: A requirements workshop can be defined as a structured and facilitated event for getting carefully selected stakeholders together to discover, refine, prioritize, validate and discuss requirements. A skilled facilitator usually manages workshop sessions.
Workshop provides excellent opportunity to get everyone together in one shared location whether it’s physically in a room or vive a web conference. They are valuable when there is not much time available or we cannot afford the cost to send a person out to interview.
Well carried out workshops provide the following advantages:
• Bigger view – having all stakeholders in one place to gain complete understanding of all issues and problems
• Speed – Quicker to get everyone together then individually and going back and forth.
• Acceptance – Getting stakeholders on side by accepting the project
• Group agreement – Increased chance of stakeholders taking ownership if they feel involved.
JAD sessions: Joint application development is an effective way of collecting information from the subject matter experts in the presence of the development and the testing teams to also provide their feed backs on what’s feasible, non-feasible and difficult to achieve.
A business analyst during the JAD session can be a scribe or act as a facilitator
Scribe: The role is to note the opinions that are being discussed and must not provide any own opinions on the discussions.
Facilitator: Is required to run the show, must take care of multiple aspects such as keeping the topic within the agenda, track on whether all the questions are being answered, justification to the agenda.
Interview: interview as a systematic approach for eliciting information from a person (or a group of people) in an informal or formal setting by asking questions and documenting the responses.

Interviews are one of the most popular business analysis techniques. They can be used to verify facts, clarify ambiguity, trigger enthusiasm, engage end users, identify requirements and solicit opinions and ideas.

Why opt for an interview above other techniques?
• Interviews offer the analyst an opportunity to establish rapport and trust with the interviewee. By conducting a face-to-face meeting, the analyst can start a cordial relationship with the interviewee to make them feel involved in the project.
• Interviews allow the interviewee to respond freely and openly to questions, especially when the location is private.
• Interviews provide an opportunity for the analyst to ask follow-up questions or re-word the question to get instant feedback from the interviewee.
• Interviews present an opportunity for the analyst to observe non-verbal cues. It is not everything that an interviewee can put into words.
Prototyping: prototyping produces “mock ups” of the screens or report layouts for an application. Business users often find prototyping to be a comfortable, concrete means to identify, describe and verify their interface needs.
Prototyping can be categorized in two ways:
The functional scope of the prototype:
• Horizontal prototype: Models a shallow, and possibly wide, view of the system’s functionality. Typically does not have any business logic running behind the visualization.
• Vertical prototype: Models a deep, and usually narrow, slice of the entire system’s functionality.
The use of the prototype throughout the system development lifecycle:
• ‘Throw-away’ Prototype: This exploratory approach seeks to quickly uncover and clarify interface requirements using simple tools, sometimes just paper and pencil. As the name suggests, ‘Throw-away’, such a prototype is usually discarded when the final system has been developed. The focus is on functionality that is not easily elicited by other techniques, has conflicting viewpoints, or is difficult to understand.
• Evolutionary Prototype: This rigorous approach extends the initial interface requirements into a fully functioning system and requires a specialized prototyping tool or language. This prototype produces “running” software. It emerges as the actual system downstream in the lifecycle.

Questionnaire: A survey administers a set of written questions to the stakeholders and subject matter experts. Their responses are analysed and distributed to the appropriate parties.
Questions in a survey are of two types:
• Closed: The respondent is asked to select from available responses. Useful when the issues are known but the range of user responses to them is not. The responses to closed questions are easier to analyse than those gained from open-ended questions.
• Open-ended: The respondent is free to answer the questions as they wish. Useful when the range of user’s responses is pretty well understood, but the strength of each response category needs to be determined. The responses to open-ended questions may provide more detail and a wider range of responses than those gained from closed-ended questions but open-ended questions are more difficult to quantify and summarize.