Writing Functional Specifications Class 6 PHP MySQL Writing Functional Specifications Reference: http://www.w3schools.com/php/

Functional Specification (Requirements – Inception) Minimum necessary documentation to begin formal design and implementation Forms common denominator for all stake holders Formal design in UML (Elaboration) Implementation and testing (Construction) System deployment (Transition) Homework 6 & 7 – Functional Specification Homework 8 – Function specification briefing Homework 9 – Sprint 1

Typical Product Life Cycle Why? What? How? Execute! Requirements Analysis Design & Development Production Operation & Maintenance Concept Development Phase Out & Disposal B19 or B42

Product Life Cycle Concept Development Identify customer needs The consumer/user need is identified as a basic concept. It is later expanded to include features which are simply desirable. Product Planning Function Marketing analysis, feasibility study, advanced product planning. Product Research Function. Basic research and applied research. Evolution from basic research to product design and development. Product Requirements & Design Function. Design requirements, conceptual design, preliminary system design, and detailed design. Prototyping, and transition from design to production. Production and Construction. Production requirements, operational analysis, and manufacturing. Methods engineering, production control. Product Evaluation Evaluation requirements, test preparation phases, formal test and evaluation. Data collection, analysis, reporting, corrective action, retesting. Product Operation & Maintenance Product is distributed to the consumer/user and in operational use. Production team supports users and performs maintenance activities. Product phase-out, disposal, or recycle.

Development Life Cycle Models Each life cycle phase is completed before the next is started. After requirements are established, design, code and test is done in overlapped stages. Multiple iterations are done throughout the life cycle. WATERFALL INCREMENTAL PHASED EVOLUTIONARY TRANSFORM SPIRAL Agile System evolves based on prototype versus an established set of requirements. Automatic transformation of a formal specification into code. Repetition of cycles, where each cycle involves same or similar steps (e.g., prototyping). On the final spiral the final product is produced. Scrum or similar implementation, rapid iterations of features on feature backlog.

Spiral Model Cumulative cost Risk analysis Operational Prototype Unit test Integration and Code Detailed design Risk analysis Determine objectives, alternatives, and constraints Progress through steps Commitment Partition Review Evaluate process alternatives; identify, resolve process risks Implementation Formal Software product Design validation and verification Requirement validation reqmts Concept of operation Develop- ment plan Integration and test plan Determine process object, alternatives, constraints Develop, Verify next-level process plans Evaluate alternatives; identify, resolve risks Next-Level Product Reqmts plan Life cycle P1 Figure based on the concept by Barry Boehm published in Information Technology in Action, Prentice Hall, 1993. Characterized by Potential for multiple deliveries Potential for multiple execution of phase specific processes Planning on a spiral basis Each spiral passes through 4 stages: Determine objectives, alternates, and constraints Evaluate alternates, identify and resolve risks Develop and verify current level product Plan for next spiral Each spiral requires customer approval to proceed Standard life cycle phases are executed only in the development phase - precisely what is done is a program decision Prototypes are used primarily to assess risk, not as a basis for product development Advantages Include: Focus on reducing risk High-risk requirements are identified, implemented, and evaluated using Prototyping Provides a formal opportunity to determine completion or redirection of the development effort May be applied to individual system components independently Challenges Include: Rework of prototypes is usually required At its core, a spiral may still be waterfall development Completion opportunity not likely to be exercised on multi-year contracts Some difficulty in overall planning and costing Deliverables may not be well defined Perception of low value added quadrants

Development Model Thoughts There is no magic model – they are largely the creation of academia Many experienced software & systems engineers create development life cycles as needed In particular, rapidly evolving software technology leaves most standard models in the dust Don’t be afraid to experiment!

A Simplified Software Engineering Process Inputs... • Environment Management • Technology Base • Plan Outputs from Prior Phase • Manage Risk • Program Decisions • Assess • Requirements • Control Applied Through Regulations, Specifications and Standards Outputs of Systems Engineering Process Outputs… Technical • Baselined Set of requirements • Requirements • Final software design • Design Final Code & Executable • Implementation • Final software tests • Testing • Well Defined Engineering Process

One of the Agile Methods Scrum One of the Agile Methods

Scrum Start the Scrum Process - A chicken and a pig are together when the chicken says, "Let's start a restaurant!". The pig thinks it over and says, "What would we call this restaurant?". The chicken says, "Ham n' Eggs!". The pig says, "No thanks, I'd be committed, but you'd only be involved!". Define the team consisting of pigs (people who are assigned work) and chickens (people who are interested, but are not working). Identify pigs that will compose the Scrum team. Appoint Scrum Master - The Scrum Master is the person who conducts the Scrum meetings, empirically measures progress, makes decisions, and gets impediments out of the way of slowing or stopping work. This is often the engineering or marketing manager for this product or system area. Establish and Conduct Daily Scrum Meeting - The daily Scrum meeting is a status check where the team meets and updates each other about what's going on. It provides a daily focus on the work being done. Identify Backlog - Backlog is all of the work that is outstanding for a product area, both immediate and well-defined, and long terms and visionary. Create Sprint Goal and Backlog - The team selects a cohesive group of top priority backlog, that - once completed - will have reached an objective, or milestone. This is stated as the Sprint's objective. During the Sprint, the team is free to not do work as long as this objective is reached. The team now decomposes the selected backlog into tasks. These tasks are discrete pieces of work that various team members sign up to do. Tasks are performed to complete backlog to reach the Sprint objective. Sprint - For thirty days, the team works on the sprint goal and backlog. Every day there is a Scrum meeting. Impediments are removed. No additional backlog can be added to the Scrum team, nor can team members be removed. During the Sprint, outside chaos is not allowed into the Sprint. As workers perform the assigned, incremental work, they will have enough complexity and chaos to deal with. By buffering the workers from outside disturbances, they are free to focus on the work at hand and do the best they can. End of Sprint Demonstration - The end of Sprint demo is an opportunity for the development team to demonstrate that it has met the objectives planned at the beginning of the Sprint. The end of Sprint demo should be viewed as method of bring together all interested parties involved in the product development. Formulate next Sprint - After the meeting has been completed, the product manager, team leader, and team should schedule a short follow-up meeting to review the details of the meeting and review areas that can be improved during the next end of Sprint demo. The meeting should also address the setting of goals and objectives for the next Sprint as well as the schedule for the next Sprint.  

Scrum Sprint Cycle Planning Sprint Cycle In this phase, the project is planned and high-level design decisions are made. Sprint Cycle                                                                                                                                            

Scrum Sprint Cycle cont. The sprint cycle is: an iterative cycle of about 3-4 weeks in which the actual development of the product is done starts with a Sprint Planning Meeting to decide what will be done in the current sprint development is done A sprint is closed with a Sprint Review Meeting where the progress made in the last sprint is demonstrated Sprint is reviewed, and adjustments are made to the project as necessary The sprint cycle is repeated until the product's development is complete. The product is complete when the variables of time, quality, competition and cost are at a balance. Develop the product further - implement, test, and document. Wrap up the work - get it ready to be evaluated and integrated. Review the work done in this sprint. Adjust for any changes in requirements or plans. Closure In this phase, the product's development is brought to a close, and the product is released.

Sprint Product Life Cycle Weekly Review Daily Scrum Product Release Plan Test & Document Analyze/Maps Requirements B19 or B42 Production

Our Scrum I am the scrum master You are the project lead You create the functional spec (2-3 Wks) You plan the 1 week sprints (homework) You demo your sprint each week to the class You status your sprint and sprint plan

Functional Specifications Functional Specification – Joel on Software Parts 1 to 4 What Time Is It – Example Aardvark – Example

Our Functional Spec HTML Functional Specification with links to artifacts (Folder) Project Description (word) User Conops (how the user sees the product) System Conops (perspective of technology) Requirements Table (id, description, sprint no., date complete) (Folder) UI Storyboard (your favorite graphics editor or html) Screen Flow Diagrams (a -> b -> c Screen prototypes (Folder) Business Processes (Argo UML) Activity Diagrams Class Diagrams Sequence Diagrams (Folder) Feature Backlog (Excel) Prioritized List of features and requirements Sprint Plan – Assign features to sprints Percent Complete

Base App Project Homework for implemented Download Project BaseApp.0.0.2.zip Class to discuss the source code and operations of the Base App Project

Homework 7, 8, 9 Read Joel-On-Software articles Begin your functional spec Think of a project Create Project Description Create UI story boards Create UML Models Create Sprint plan/backlog Due 10/24/2006 – Present to class