You're about to create your best presentation ever

Presentation Requirements Template

Create your presentation by reusing one of our great community templates.

Requirements Presentation

Transcript: Acceptance Criteria Introduction Risk Matrix The Spiral Model Identifying the (social) circles of life 4 Important Values of Agile: Individuals and interactions. Working software. Customer collaboration. Change. As an administrator, I want to be able to: Fix bugs. Add new features. Monitor the consumer base. Initial Considerations: Extrapolate ideas and choose a direction for the final product. Define a clear set of requirements to work towards. Research metrics for friendship strengths. Organise the group playing to individual members strengths. Chose which social networks. Useable by more than one person. Be given permission to access users data. Manually change generated data. Store queried data for future use. Use data for commercial purpose. Data presented in an easy to interpret format. Prevent personal data access without permission. Caching images and static content. Caching the frequent queries. Using a CDN (Content Distribution Network). Host downloadable files offsite (such as Amazon S3). Since end-user requirements are hard to obtain/define, it is natural to develop software in an experimental way: Build some software. See if it meets customer requirements. If no then repeat. Key idea: on each iteration identify and solve the sub-problems with the highest risk. This loop approach gives rise to structured iterative life cycle models. In 1988 Boehm developed the spiral model as an iterative model which includes risk analysis and risk management. As a user, I want to be able to: See who my closest friends are across multiple social media sites. See how close I am with certain friends. See how many connections I have. Choose which social media sites I use. Grant permission. Have the ability to manually change the results. Share the results with friends. See where the people are who I interact with. Compiled Research - Appropriate Social Media Sites The Waterfall Model - Pros & Cons The Waterfall Model Professional issues to consider: We must make sure we only keep data from users from whom we have obtained full consent. Making sure all laws are complied with. If not we may be liable under criminal law. Make sure we are receiving the correct form of consent. Express declaration of consent is needed, implied consent is not clear enough. Software Development Methods RASCI Chart (Responsibility assignment matrix) Compiled Research - Computational Challenges There are three key software development methodologies: Waterfall Model Spiral Model Agile Development Various different methods but all have the same principles: Timescale is fixed. Develop small. 80/20 rule. Testing. Collaborative & cooperative approach. Disadvantages: Needs to implemented properly. Difficult to scale up to large projects. Project brief: Create a Social Media "friend mapper". For an individual Social Media user the application should map the users network of "friends". Map these links based on strengths and weaknesses. Map "friends" in circles closest nearest the user and working outwards. Identify family members. Risk probability and impact - statistics Legal Issues cont. MOSCOW Requirements - Functional Requirements Compiled Research Risk Analysis - Technology & Tools Choice of 2 Types: Decentralized (egoless) control teams. Mixed Control Teams. We should adopt the Decentralized Control Team. Why? Connected communication. Decisions shared. Goals set by consensus- which already happens. Leadership dictated by -Ability, experience and expertise. Rolling project manager every week meaning that there is no stress on one person, and responsibility is shared between the group. Requirements Stage: User requirements and constraints are worked out. A preliminary study might be carried out. Acceptance criteria is developed. Deliverable: the requirement specification. Design Stage: Overall architecture. Interface between components and between the system and its environment are defined. Algorithms are developed and data structures are specified. Integration: Individual components are integrated to form the complete system. System is tested as a whole. Advantages: Iterative. Produces good team cohesion. Emphasis final product. Limitations: Quantity of social network server requests. Dunbar’s Number – maximum maintainable relationships is between 100 and 250; other studies propose 290 as the actual mean. Risk Analysis Risk Analysis - People Agile Development - Pros & Cons Acceptance Criteria - cont. Factors that affect friendship strength... Intensity Intimacy Duration Reciprocal services Social structure Emotional support Social distance Rejection of Waterfall: Effectiveness of requirements. Dissatisfied with delivered software. Choosing Agile : See the work being delivered. Potential Impact: Example Easy to use interface. Results are easy to interpret. Easy integration with chosen Social Media sites. Consistent application styling. Well known and legible fonts. Full Data Protection Act compliance. Copyright, Designs and Patents Act

Presentation requirements

Transcript: COMPANY NAME STORY TITLE LOGO Presentation Requirements ACT 1 -Prepare your presentation in MS PowerPoint formar and save it on a disk.CD-ROM or USB memory stick.All presentation will be presented at a resolution of 1024 by 768 pixels on a PC with Windows XP and PowerPoint XP. -Your presentation shold be prepared in MS PowerPoint 97 or hogher. ACT 2 -Check your presentation in the session room in advance. -Be in the session room at least 10 minutes besore the session starts to meet the chair of the session - ACT 3 -Use high-contrast colors:Light text on dark background or vice versa. -Use high-contrast lettering and readable fonts.The minimum front size is 24. -Duration for oral presentation:15 min 1.Preparation,preparation,preparation 2.Think audience 3.Communicate 4.Prepare the little things 5.Structure your presentation 6.Finding your voice 7.Do not reaf or read like you mean it 8.Non-verbal communication 9.Slide design 10.Practice,practice,practice. 10 Tips for a Good Presentation Presenting authors are requested to display their posters in poster exhibition area.Authors sre required to be present beside their posters during the respective sessions.Posters must be put in person and taken off promptly at the end of the conference.Printed posters should not exceed:90 cm (wifth x 120cm (height)(35,5 in x 47,24 in) recommended poster size is A0 Poster Presentations 1.present the article 2.explain the major point made by rhe author 3.present the arguments given along with the evifence used as support 4.link the points or arguments presented to ethical theory Group Presentation Requirements THANK YOU FOR ATTENTION!!!

Requirements Template

Transcript: This section describes User and System Interface requirements for the proposed system. There will be links to these Development dociuments. In this section you will identify if any of the requirements are out of scope. For example if you are writing requirements for a multi-phase project, there may be some requirements documented that will not come into play until later but it was important to document them now so that "Final Big Vision" is not lost. This is the section you call out what is in scope NOW. The first step to writing requirements is to perform discovery to learn as much as possible about the source and reason for the request. After you have compiled notes and completed the discovery phase and checked off the items on the checklist, it is time to begin writing the business requirements. Please be sure to begin with the BRD template. Business Requirements Document (BRD) Another very important part of keeping track of the version you are working with in addition to the cover page is the Revision Log. Be sure to update any changes made after the first draft review. Interface Requirements User Acceptance Testing Be sure to include the date and the stakeholders involved. If someone abstains that is counted as approval, only stakeholders against the requirements are documented as such with their reasoning. QA Testing In this section document any assumptions you have made when writing the requirements. For example, you are designing a screen with the assumption that all of its users will be power users. You should document that assumption. This is the section we have been waiting for. In Scope Assumptions In this section you will document the business requirements. Remember, these are the "WHAT" not the how. The last section to be completed on the BRD is the Approval section. This section addresses the functionality desired.What capabilities are expected as a result of this project. Again as with the Business Requirements, focus on "WHAT" functions not "how" they will. Requirements Template System Interface Requirements Cover Page Requirements Scope Business Requirements Unit Testing This section describes the risks that were identified prior to or during the Business Requirements gathering and documentation. Goals/ Objectives/ Benefits Functional Testing Test Plan The BRD This section will be addressed in the Development documents. The link to the documents will be placed in this section for reference for all documentation in one place. This is how the System interacts with o ther systems. These are both WHAT and HOW.. Other Considerations There will be links in these sections to the testing documentation. Risks User Interface Requirements This presentation will review the current BRD template and the steps to complete it. The checklist Project Background The Details This section describes the dependencies between the Application for which these Business Requirements are written and the other existing applications/systems. The first section of the BRD is Project Background. This is where you will use the discovery information you documented. The purpose fo this section is to understand the reason for the request. What is the result the customer / user is looking for and why? What is the problem they are trying to solve? One of the tools to perform discovery and elicit the business requirements is the checklist. Constraints Revision Log Hardware/Software Requirements Constraints are needed so that you restrict the scope to something that is true and manageable. When I say true, I mean that the customer or user can’t come back later saying that you need to add 100 more requirements. An example: The proposed system will only be used by Company X’s employees Replace any section with <Brackets and Blue Text> with the appropriate information. <Purple Text> is updated when submitted for sign off. <Red Text> is updated when any revisions are made after first draft is reviewed. In this section, write an overview of the objective or gaol of the requirements. What is the end product expected to be? Dependencies on Existing Systems Technical Requirements Checklist This is how the USERs interact wiht the system. These are both WHAT and HOW. Discovery Out of Scope Functional Requirements

Now you can make any subject more engaging and memorable