PowerPoint Presentation

Documentation-By RatneshGood 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 .1

Documentation needTypesRequirement documentsGathering requirementsSeparating concernIn AgileStory vs requirement docExample with toolDiagramsQ & A1/21/2015Talentica Software2Documentation need

1/21/2015Talentica Software

Documentation need

1/21/2015Talentica Software

Documentation need

1/21/2015Talentica Software

Documentation need

1/21/2015Talentica Software

Documentation need

New IdeasImpact Analysis1/21/2015Talentica Software

Documentation need, Complex

1/21/2015Talentica Software

Documentation need , Decision making 1/21/2015Talentica Software

Documentation , How Much ?

1/21/2015Talentica Software

Documentation , How Much ?

1/21/2015Talentica Software

Documentation , Agile?

1/21/2015Talentica Software

Documentation , Agile?

1/21/2015Talentica Software

DocumentationMaintenanceWikiVersioningIntegration with source controlIntegration with Jira

1/21/2015Talentica SoftwareDocument , TypesRequirementsArchitecture/DesignTechnicalEnd userMarketing1/21/2015Talentica Software

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, andAPIs.End user- Manuals for the end-user, system administrators and support staff.Marketing - How to market the product and analysis of the market demand.15Requirement Documents1/21/2015Talentica SoftwareRequirement Documentswhat a particularsoftwaredoes or shall doagreementproduced and consumed by everyone

1/21/2015Talentica SoftwareRequirement Documentsvariety of styles, notations and formalitygoal-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/2015Talentica SoftwareRequirement Documents, Specsnatural languagedrawn figuresas detailedmathematical formulasas a combination of them all

1/21/2015Talentica SoftwareRequirement Documents, challengesvariation and complexityimplicit and hard to uncoverexactly how much and what kind of documentation is neededhow much can be left to the architecture and design documentationvariety of people1/21/2015Talentica Softwareequirements documentation is often incomplete (or non-existent). Without proper requirements documentation, software changes become more difficult and therefore more error prone (decreasedsoftware quality) and time-consuming (expensive).20Requirement Documents, Needcomplexity of the productimpact of the productlife expectancyof the software

1/21/2015Talentica Software. 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 managementtools are advocated.

211/21/2015Talentica Software

Requirement Documents, Agile1/21/2015Talentica SoftwareRequirement Documents, Agile1/21/2015Talentica Software

Requirement Documents, Agile , WhyDo It For The TeamDo It For The Users

1/21/2015Talentica Software25Requirement Documents, Agile, WhoHello Product Owner1/21/2015Talentica Software

Requirement Documents, Agile, WhatThree StepsGet the initial listWrite the user stories Add the acceptance criteria

1/21/2015Talentica SoftwareRequirement Documents, Agile, What#1: Initial List Start with the who and whatBulleted-listNon-technical Start with a story of who is doing what in the applicationA literal story

1/21/2015Talentica SoftwareRequirement Documents, Agile, What#2: Write the StoriesAs a [role]I can [do something]So that I [get some benefit]

1/21/2015Talentica Software1/21/2015Talentica Software

Requirement Documents, Agile, What, StoriesRequirement Documents, Agile, What, Stories

Quick Tip #1If you cant state a benefit, then you might not need that feature.1/21/2015Talentica SoftwareRequirement 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/2015Talentica SoftwareRequirement Documents, Agile, WhenWhen We WriteWrite an initial list before the project startsHave your high priority stories fleshed out 2-3 sprints ahead

1/21/2015Talentica SoftwareRequirement Documents, Agile, WhenQuick Tip #2Try to hold off on writing acceptance criteria until closer to the time you are going to design or develop a feature.1/21/2015Talentica SoftwareRequirement Documents, Agile, ExampleTool usedMindMap :- Xmind , MindInject

1/21/2015Talentica SoftwareRequirement Documents, Agile, ExampleMindMap Template1/21/2015Talentica Software

Requirement Documents, Agile, ExampleSocial Network1/21/2015Talentica Software

Requirement Documents, Agile, ExampleStart With The Roles1/21/2015Talentica Software

Requirement Documents, Agile, ExampleAdd Role Details1/21/2015Talentica Software

Requirement Documents, Agile, ExampleWhat Can They Do?1/21/2015Talentica Software

Requirement Documents, Agile, ExampleWhats the Benefit?1/21/2015Talentica Software

Requirement Documents, Agile, ExampleQuick Tip #3If we can describe each role before writing what they can do, then the what and benefit comes much easier

1/21/2015Talentica SoftwareRequirement Documents, Agile, ExampleUse Case?1/21/2015Talentica Software

Requirement Documents, Agile, ExampleQuick Tip #4Dont worry about the so what partMore benefits are good1/21/2015Talentica SoftwareRequirement Documents, Agile, ExampleThe Full Monty1/21/2015Talentica Software

Requirement Documents, Agile, ExampleUser Story ExampleAs a Site Visitor, I can browse marketing pages, so that I can learn more about the benefitsAcceptance CriteriaThe marketing pages should be controlled by a CMSThe pages should render in less than 2 secondsShould render properly in IE8, FF 3.x, Safari 3.x, and Google Chrome1/21/2015Talentica SoftwareRequirement Documents, Agile, Story writingA user story describes functionality that will be valuable to either a user or purchaser of a system or software

1/21/2015Talentica SoftwareRequirement Documents, Agile, Story writingIs 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 documentationUI mockup1/21/2015Talentica SoftwareRequirement Documents, Agile, Story writing1/21/2015Talentica Software

Requirement Documents, Agile, Story writing1/21/2015Talentica Software

Requirement Documents, Agile, Story writing1/21/2015Talentica Software

Requirement Documents, Textual Analysis1/21/2015Talentica Software

Requirement Documents, Requirement diagram1/21/2015Talentica Software

Requirement Documents, Requirement diagram1/21/2015Talentica Software

Requirement Documents, ArchiMatevisualize relationships within and between different domainsdomains primarily include products/services, processes, organization, data applications and technical infrastructure1/21/2015Talentica SoftwareRequirement Documents, ArchiMate1/21/2015Talentica Software

Requirement Documents, ArchiMate1/21/2015Talentica Software

Requirement Documents, Requirement grid1/21/2015Talentica Software

Requirement Documents, CRC card diagram1/21/2015Talentica Software

Requirement Documents, Gathering tipsaccept you will never hit 100% accuracyAsk Why? Ask it a lot.as few people as possiblea dedicated scribeuse dialogue mapping Fast deliveryImperfect final report

1/21/2015Talentica SoftwareFirstly, 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 wont 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.

60Requirement Documents, Gathering techniquesOne-on-one interviewsGroup interviewsFacilitated sessionsJoint application development (JAD)QuestionnairesPrototypingUse casesFollowing people aroundRequest for proposals (RFPs)Brainstorming

1/21/2015Talentica Software#1: One-on-one interviewsThe 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 interviewsGroup 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 sessionsIn 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: QuestionnairesQuestionnaires 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: PrototypingPrototyping 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 casesUse 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 aroundThis 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: BrainstormingOn 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.

611/21/2015Talentica Software