1. Writing Functional Specifications
Class 6 PHP MySQL
Writing Functional Specifications
Reference:

2. 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

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

4. 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.

5. 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.

6. 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

7. 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!

8. 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

9. One of the Agile Methods
Scrum
One of the Agile Methods

10. 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.

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

12. 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.

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

14. 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

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

16. 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

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

18. 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