Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (19)
Similaire à requirement documentation
Similaire à requirement documentation (20)
Plus de ratneshsinghparihar
Plus de ratneshsinghparihar (10)
Dernier
Dernier (20)
requirement documentation
- 1. -By Ratnesh
- 2. Documentation need Types Requirement documents Gathering requirements Separating concern In Agile Story vs requirement doc Example with tool Diagrams Q & A 1/21/2015 Talentica Software
- 3. Documentation need 1/21/2015 Talentica Software
- 4. Documentation need 1/21/2015 Talentica Software
- 5. Documentation need 1/21/2015 Talentica Software
- 6. Documentation need 1/21/2015 Talentica Software
- 7. Documentation need New Ideas Impact Analysis 1/21/2015 Talentica Software
- 8. Documentation need, Complex 1/21/2015 Talentica Software
- 9. Documentation need , Decision making 1/21/2015 Talentica Software
- 10. Documentation , How Much ? 1/21/2015 Talentica Software
- 11. Documentation , How Much ? 1/21/2015 Talentica Software
- 12. Documentation , Agile? 1/21/2015 Talentica Software
- 13. Documentation , Agile? 1/21/2015 Talentica Software
- 14. Documentation Maintenance Wiki Versioning Integration with source control Integration with Jira 1/21/2015 Talentica Software
- 15. Document , Types Requirements Architecture/Design Technical End user Marketing 1/21/2015 Talentica Software
- 16. Requirement Documents 1/21/2015 Talentica Software
- 17. Requirement Documents what a particular software does or shall do agreement produced and consumed by everyone 1/21/2015 Talentica Software
- 18. Requirement Documents variety of styles, notations and formality goal-like (e.g., distributed work environment) close to design (e.g., builds can be started by right- clicking a configuration file and select the 'build' function) anything in between 1/21/2015 Talentica Software
- 19. Requirement Documents, Specs natural language drawn figures as detailed mathematical formulas as a combination of them all 1/21/2015 Talentica Software
- 20. Requirement Documents, challenges variation and complexity implicit and hard to uncover exactly how much and what kind of documentation is needed how much can be left to the architecture and design documentation variety of people 1/21/2015 Talentica Software
- 21. Requirement Documents, Need complexity of the product impact of the product life expectancy of the software 1/21/2015 Talentica Software
- 23. Requirement Documents, Agile 1/21/2015 Talentica Software
- 24. Requirement Documents, Agile 1/21/2015 Talentica Software
- 25. Requirement Documents, Agile , Why Do It For The Team Do It For The Users 1/21/2015 Talentica Software
- 26. Requirement Documents, Agile, Who Hello Product Owner 1/21/2015 Talentica Software
- 27. Requirement Documents, Agile, What Three Steps Get the initial list Write the user stories Add the acceptance criteria 1/21/2015 Talentica Software
- 28. Requirement Documents, Agile, What #1: Initial List • Start with the who and what Bulleted-list Non-technical • Start with a story of who is doing what in the application A literal story 1/21/2015 Talentica Software
- 29. Requirement Documents, Agile, What #2: Write the Stories As a [role] I can [do something] So that I [get some benefit] 1/21/2015 Talentica Software
- 30. 1/21/2015 Talentica Software Requirement Documents, Agile, What, Stories
- 31. Requirement Documents, Agile, What, Stories Quick Tip #1 If you can’t state a benefit, then you might not need that feature. 1/21/2015 Talentica Software
- 32. Requirement Documents, Agile, What #3: Acceptance Criteria • Defines done • As much as you need for task breakdown • Mockups • Design is 1-2 sprints ahead of development 1/21/2015 Talentica Software
- 33. Requirement Documents, Agile, When When We Write Write an initial list before the project starts Have your high priority stories fleshed out 2-3 sprints ahead 1/21/2015 Talentica Software
- 34. Requirement Documents, Agile, When Quick Tip #2 Try to hold off on writing acceptance criteria until closer to the time you are going to design or develop a feature. 1/21/2015 Talentica Software
- 35. Requirement Documents, Agile, Example Tool used MindMap :- Xmind , MindInject 1/21/2015 Talentica Software
- 36. Requirement Documents, Agile, Example MindMap Template 1/21/2015 Talentica Software
- 37. Requirement Documents, Agile, Example Social Network 1/21/2015 Talentica Software
- 38. Requirement Documents, Agile, Example Start With The Roles 1/21/2015 Talentica Software
- 39. Requirement Documents, Agile, Example Add Role Details 1/21/2015 Talentica Software
- 40. Requirement Documents, Agile, Example What Can They Do? 1/21/2015 Talentica Software
- 41. Requirement Documents, Agile, Example What’s the Benefit? 1/21/2015 Talentica Software
- 42. Requirement Documents, Agile, Example Quick Tip #3 If we can describe each role before writing what they can do, then the what and benefit comes much easier 1/21/2015 Talentica Software
- 43. Requirement Documents, Agile, Example Use Case? 1/21/2015 Talentica Software
- 44. Requirement Documents, Agile, Example Quick Tip #4 Donʼt worry about the “so what” part More benefits are good 1/21/2015 Talentica Software
- 45. Requirement Documents, Agile, Example The Full Monty 1/21/2015 Talentica Software
- 46. Requirement Documents, Agile, Example User Story Example As a Site Visitor, I can browse marketing pages, so that I can learn more about the benefits Acceptance Criteria The marketing pages should be controlled by a CMS The pages should render in less than 2 seconds Should render properly in IE8, FF 3.x, Safari 3.x, and Google Chrome 1/21/2015 Talentica Software
- 47. Requirement Documents, Agile, Story writing A user story describes functionality that will be valuable to either a user or purchaser of a system or software 1/21/2015 Talentica Software
- 48. Requirement Documents, Agile, Story writing Is An agreements between customers and team members to discuss detail requirements during an iteration • Emphasize verbal rather than written communication. • Right size for planning Is not A Requirement document, requirement need to be captured by discussion , if discussion is not possible then should be augmented by documentation UI mockup 1/21/2015 Talentica Software
- 49. Requirement Documents, Agile, Story writing 1/21/2015 Talentica Software
- 50. Requirement Documents, Agile, Story writing 1/21/2015 Talentica Software
- 51. Requirement Documents, Agile, Story writing 1/21/2015 Talentica Software
- 52. Requirement Documents, Textual Analysis 1/21/2015 Talentica Software
- 53. Requirement Documents, Requirement diagram 1/21/2015 Talentica Software
- 54. Requirement Documents, Requirement diagram 1/21/2015 Talentica Software
- 55. Requirement Documents, ArchiMate visualize relationships within and between different domains domains primarily include products/services, processes, organization, data applications and technical infrastructure 1/21/2015 Talentica Software
- 56. Requirement Documents, ArchiMate 1/21/2015 Talentica Software
- 57. Requirement Documents, ArchiMate 1/21/2015 Talentica Software
- 58. Requirement Documents, Requirement grid 1/21/2015 Talentica Software
- 59. Requirement Documents, CRC card diagram 1/21/2015 Talentica Software
- 60. Requirement Documents, Gathering tips accept you will never hit 100% accuracy Ask “Why?” Ask it a lot. as few people as possible a dedicated scribe use “dialogue mapping” Fast delivery Imperfect final report 1/21/2015 Talentica Software
- 61. Requirement Documents, Gathering techniques One-on-one interviews Group interviews Facilitated sessions Joint application development (JAD) Questionnaires Prototyping Use cases Following people around Request for proposals (RFPs) Brainstorming 1/21/2015 Talentica Software
Notes de l'éditeur
- Good Morning Everyone. My name is Ratnesh and I am a .net developer in talentica for last 5 years. Today I am going to give a presentation on windows azure . This presentation consists of my conclusions of readings and experiments with Azure , so feel free to disagree .
- Requirements - Statements that identify attributes, capabilities, characteristics, or qualities of a system. This is the foundation for what shall be or has been implemented. Architecture/Design - Overview of software. Includes relations to an environment and construction principles to be used in design of software components. Technical - Documentation of code, algorithms, interfaces, and APIs. End user - Manuals for the end-user, system administrators and support staff. Marketing - How to market the product and analysis of the market demand.
- equirements documentation is often incomplete (or non-existent). Without proper requirements documentation, software changes become more difficult — and therefore more error prone (decreased software quality) and time-consuming (expensive).
- . If the software is very complex or developed by many people (e.g., mobile phone software), requirements can help to better communicate what to achieve. If the software is safety-critical and can have negative impact on human life (e.g., nuclear power systems, medical equipment), more formal requirements documentation is often required. If the software is expected to live for only a month or two (e.g., very small mobile phone applications developed specifically for a certain campaign) very little requirements documentation may be needed. If the software is a first release that is later built upon, requirements documentation is very helpful when managing the change of the software and verifying that nothing has been broken in the software when it is modified. Traditionally, requirements are specified in requirements documents (e.g. using word processing applications and spreadsheet applications). To manage the increased complexity and changing nature of requirements documentation (and software documentation in general), database-centric systems and special-purposerequirements management tools are advocated.
- Firstly, accept you will never hit 100% accuracy. Bear it in mind at all times and it will drive you to capture better requirements. Spend as long as you possibly can on this phase and talk to as many people as possible. Talk to people in a wide range of roles, but ask them all the same questions. You will be surprised how good an insight staff “on the shop floor” have about so called “management level” questions (and vice versa). Ask “Why?” Ask it a lot. Never accept an answer in the requirements gathering phase without asking “why” at least five times. No matter the project, the technology, the company or the interviewee — “Why?” is the best question. Requirements gathering has to be conducted by as few people as possible. Imagine a different consultant carrying out each meeting in the scenario described above. Our percentage would plummet. If more than one person is really needed (and avoid it if you can), then the process has to be headed up and coordinated by a single person. Some single person must hold the whole problem in their head. Always have a dedicated scribe. In meetings and workshops, the person conducting the session should never write the notes. If they are doing a good job (see the first point), then they just won’t have time. Better still, use “dialogue mapping” techniques to document meetings. There is not enough room to go into this topic here, but this involves a dedicated scribe documenting decisions and questions using diagrams on a big screen that everyone can see. Deliver outputs of requirements gathering to the client as often as possible. Always send them a copy of your raw meeting notes. Then follow up meetings with your findings. If you need to produce a formal report, go over your thinking and draft copies with the client as early as possible. Your final report will not be perfect, so when development starts, keep talking to the client. If possible, keep showing them the solution as you build it to check your theories and ideas.
- #1: One-on-one interviews The most common technique for gathering requirements is to sit down with the clients and ask them what they need. The discussion should be planned out ahead of time based on the type of requirements you're looking for. There are many good ways to plan the interview, but generally you want to ask open-ended questions to get the interviewee to start talking and then ask probing questions to uncover requirements. #2: 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. These interviews work well when everyone is at the same level or has the same role. Group interviews require more preparation and more formality to get the information you want from all the participants. You can uncover a richer set of requirements in a shorter period of time if you can keep the group focused. #3: Facilitated sessions In a facilitated session, you bring a larger group (five or more) together for a common purpose. In this case, you are trying to gather a set of common requirements from the group in a faster manner than if you were to interview each of them separately. #4: Joint application development (JAD) JAD sessions are similar to general facilitated sessions. However, the group typically stays in the session until the session objectives are completed. For a requirements JAD session, the participants stay in session until a complete set of requirements is documented and agreed to. #5: Questionnaires Questionnaires are much more informal, and they are good tools to gather requirements from stakeholders in remote locations or those who will have only minor input into the overall requirements. Questionnaires can also be used when you have to gather input from dozens, hundreds, or thousands of people. #6: Prototyping Prototyping is a relatively modern technique for gathering requirements. 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. You change the application and cycle around with the client again. This repetitive process continues until the product meets the critical mass of business needs or for an agreed number of iterations. #7: 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. Use cases may be easier for the users to articulate, although the use cases may need to be distilled later into the more specific detailed requirements. #8: Following people around This technique is especially helpful when gathering information on current processes. You may find, for instance, that some people have their work routine down to such a habit that they have a hard time explaining what they do or why. You may need to watch them perform their job before you can understand the entire picture. In some cases, you might also want to participate in the actual work process to get a hands-on feel for how the business function works today. #9: Request for proposals (RFPs) 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 to determine how close a match you are to the client's needs. #10: Brainstorming On some projects, the requirements are not "uncovered" as much as they are "discovered." In other words, the solution is brand new and needs to be created as a set of ideas that people can agree to. In this type of project, simple brainstorming may be the starting point. The appropriate subject matter experts get into a room and start creatively brainstorming what the solution might look like. After all the ideas are generated, the participants prioritize the ones they think are the best for this solution. The resulting consensus of best ideas is used for the initial requirements.