Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Crutial steps in requirement gathering

All of us must have heard this proverb umpteen number of times in our lives. However, when it comes to elicitation, we tend to forget the same.Elicitation is possibly the most important job we business analysts do. I am surprised that many of us understand only few facets of elicitation such as requirements gathering and recording.Elicitation is much more than requirements gathering and recording. A good elicitation activity can significantly reduce effort in changes in requirements and subsequent changes to design, construction and testing activities.Here is an attempt to make our elicitation exercises more effective.

Livres associés

Gratuit avec un essai de 30 jours de Scribd

Tout voir
  • Soyez le premier à commenter

Crutial steps in requirement gathering

  2. 2. Hello! I am Abhinav Sabharwal You can find me at Skyabhinav@gmail.com https://www.linkedin.com/in/abhinavsabharwal
  3. 3. ““A stitch in time saves nine.”
  5. 5. GATHER REQUIREMENTS ◎ Gather requirements from various sources, primary one being from stakeholders. Requirements can also be from existing system documentation, competitor system documentation or from existing system interfaces
  6. 6. Questionnaires Sessions REQUIREMENTS SOURSES
  7. 7. One-on-one Interviews The most common technique for gathering requirements is to sit down with the clients and ask them what they need Group interviews Group interviews are similar to the one-on-one interview, except that more than one person is being interviewed usually two to four. Use cases Use cases are basically stories that describe how discrete processes work. The stories include people (actors) and describe how the solution works from a user perspective courage. ◎Joint application development For a requirements JAD session, the participants stay in session until a complete set of requirements is documented and agreed to Questionnaires Questionnaires are much more informal, and they are good tools to gather requirements from stakeholders in remote locations Prototyping In this approach, you gather preliminary requirements that you use to build an initial version of the solution: a prototype. You show this to the client, who then gives you additional requirements. REQUIREMENTS SOURSES Request for proposals If you are a vendor, you may receive requirements through an RFP. This list of requirements is there for you to compare against your own capabilities Brainstorming The appropriate subject matter experts get into a room and start creatively brainstorming what the solution might look like Facilitated Sessions In a facilitated session, you bring a larger group (five or more) together for a common purpose.
  9. 9. ENTITY MODELLINGI Entity modeling is used to record the data that needs to be stored, and the historical facts that need to recalled at a later stage. Entity modeling also documents the relationship between entities, their primary key (what makes a record uniquely identifiable). If the system is to have a database at its core then we would recommend that an articulate DBA works with the project stakeholders CAPTURING REQUIREMENTS USER STORIES User stories record the activities that different types of operators do and their effects on the system and the data. Operators may be particular staff roles (say bookings manager) or other people that interact with the business (say customers) or even other triggers (say a timer). Often it is good practice to capture the user stories as just “titles” to start with, then priorities them, then add on the explanation in a “conservation phase”. USE CASES User Cases is a list of actions or event steps, typically defining the interactions between a role (known in the Unified Modeling Language as an actor) and a system, to achieve a goal. The actor can be a human or other external system. A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment
  10. 10. REQUIRMENTS PHASE Capture Requirments Validate Requirments Gather Requirments C o m m o n T o o l s Trace Requirements
  11. 11. Requirements analysis, also called requirements engineering, is the process of determining user expectations for a new or modified product. These features, called requirements, must be quantifiable, relevant and detailed. In software engineering, such requirements are often called functional specifications. For Analyzing requirements take the following steps 1) Make Requirements S.M.A.R.T 2) MoSCoW the Requirements 3) Classify The Requirements ANALYZE THE REQUIREMENTS
  12. 12. MAKE THEM SMART Requirements should be Specific – target a specific area Measurable – quantify or at least suggest an indicator of progress. Actionable – specify who will do it. Realistic – state what results can realistically be achieved, given available resources. Time-related – specify when the result(s) can be achieved.
  14. 14. MoSCoW ◎All requirements should be listed before commencing a project. Also, they should be ranked according to their importance. ◎ This helps the entire team know what to develop first and what to leave, in case there is a pressure on resources. ◎ MoSCoW is a method by which you can create a prioritized list of requirements. ◎ MoSCoW is essentially an acronym for Must, Should, Could, and Would: ◎By using the MoSCoW method, it is easy to prioritize which requirements should by met with first, and which can come on later. ◎A clear set of prioritized requirements, agreed with the customer, alongside the overall timescale and budget is essential.
  15. 15. MUST: These requirements are absolutely essential and indispensable for sustaining the viability of the project. The absence of these could affect project objectives. They are non- negotiable. Therefore you must have these changes. used. SHOULD: These requirements should be met with if possible but the project success does not rely on it. The absence of these could weaken the case but the project would still be capable of meeting with its objectives. COULD: These requirements are useful but they do not weaken the business case. This means you could have these, but their absence will not affect anything else in the project. WOULD: These requirements are not essential or important in any way, so they can wait. This means you would like to have these requirements later. MoSCoW
  16. 16. MoSCoW THE REQUIREMENTS Requirem ent Must Have Should Have Could Have Would Have Login Page X Two Factor Authenticati on X Social Media Login X X
  18. 18. In software project management Verification and Validation (V&V) is the process of checking that a software system meets specifications and that it fulfills its intended purpose. It may also be referred to as software quality control VERIFICATION & VALIDATION Verification is a process of evaluating the intermediary work products of a software development lifecycle to check if we are in the right track of creating the final product. Validation is the process of evaluating the final product to check whether the software meets the business needs. In simple words the test execution which we do in our day to day life are actually the validation activity which includes smoke testing, functional testing, regression testing, systems testing etc
  19. 19. VERIFICATION & VALIDATION Verification Did we built the thing right In Other words has it been built as per design Validation Did we built the right thing In Other words are the specifications correct
  20. 20. VERIFICATION & VALIDATION Criteria Verification Validation Definition The process of evaluating work-products (not the actual final product) of a development phase to determine whether they meet the specified requirements for that phase. The process of evaluating software during or at the end of the development process to determine whether it satisfies specified business requirements. Objective To ensure that the product is being built according to the requirements and design specifications. In other words, to ensure that work products meet their specified requirements. To ensure that the product actually meets the user’s needs, and that the specifications were correct in the first place. In other words, to demonstrate that the product fulfills its intended use when placed in its intended environment. Question Are we building the product right? Are we building the right product? Evaluatio n Items Plans, Requirement Specs, Design Specs, Code, Test Cases The actual product/software. Activities  Reviews, Walkthroughs & Inspections  Testing
  22. 22. TRACE REQUIREMENTS ◎ Requirements tracing is the process of recording logical links between individual requirements and other system elements. ◎ You can trace a single functional requirement backward to its origin, such as a use case, product feature or business rule. ◎ You can also trace that functional requirement forward into the bits of design, code and tests that were created because of that requirement. ◎ To do requirements traceability, the analyst must write requirements in a fine-grained fashion and give every requirement a unique and stable identifier. ◎ Start performing traceability by linking functional requirements to individual tests that verify the correct implementation of those requirements.
  23. 23. Requirment.Tracibality.Matrix
  24. 24. There are two times during each project when sign off is required on the requirements from the business The first is when the business requirements document (BRD) is complete. When the BRD is complete, you will have a sign off list of people who will read and validate the document. Usually this list includes the project sponsor, the steering committee, the IT Lead, the project manager and the business lead. Second is just prior to launch when the requirements traceability matrix (RTM) is complete. The second time you need sign off is when you have completed your requirements traceability matrix. This ensures that the solution has met the functional requirements. A third review occurs during the testing phase if any requirements cannot be met by the solution; at which time initiate a gap analysis. Usually this document is prepared while you are in testing, so any gaps identified would be noted on the gap analysis document and you can obtain sign off at the same time REQIRMENTS SIGNOFF
  25. 25. Thanks! Any questions? You can find me at skyabhinav@gmail.com