Begin Project Development: Requirements and
Feasibility
CS 370 SE Practicum, Cengiz Günay
(Some slides courtesy of Eugene Agichtein and the Internets)
CS 370, Günay (Emory) Requirements and Feasibility Spring 2014 1 / 9
Agenda
Today's events:
Team selections for main projectDemos for project1; WebIdol voting starts after class
Due after Spring Break (Tuesday, 3/18):
Project interface mock-up and object-data model designs(see class #8 notes from 2/18)
Today:
Requirements and feasibility for your new project
CS 370, Günay (Emory) Requirements and Feasibility Spring 2014 2 / 9
Agenda
Today's events:
Team selections for main projectDemos for project1; WebIdol voting starts after class
Due after Spring Break (Tuesday, 3/18):
Project interface mock-up and object-data model designs(see class #8 notes from 2/18)
Today:
Requirements and feasibility for your new project
CS 370, Günay (Emory) Requirements and Feasibility Spring 2014 2 / 9
Agenda
Today's events:
Team selections for main projectDemos for project1; WebIdol voting starts after class
Due after Spring Break (Tuesday, 3/18):
Project interface mock-up and object-data model designs(see class #8 notes from 2/18)
Today:
Requirements and feasibility for your new project
CS 370, Günay (Emory) Requirements and Feasibility Spring 2014 2 / 9
Team Selections
See Piazza thread
Need at least 3 in a team, max 5
Start working together immediately
Deadline right after Spring Break (Tuesday, 3/18)
We assign everybody now
Project1 demos (WebIdol) are at the end of class
Let's start with what you need to do with your new project!
CS 370, Günay (Emory) Requirements and Feasibility Spring 2014 3 / 9
Team Selections
See Piazza thread
Need at least 3 in a team, max 5
Start working together immediately
Deadline right after Spring Break (Tuesday, 3/18)
We assign everybody now
Project1 demos (WebIdol) are at the end of class
Let's start with what you need to do with your new project!
CS 370, Günay (Emory) Requirements and Feasibility Spring 2014 3 / 9
What is a requirement?
It is about WHAT not HOW Nothing can be said obvious Requirements are the descriptions of the services
provided by a system and its operational constraints It may range from a high level abstract statement to
a detailed mathematical specification It may be as complex as a 500 pages of description It may serve as the basis for a bid for a contract or
the basis for the contract itself
Why requirements? What are the advantages of a complete
set of documented requirements? Ensures the user (not the developer) drives
system functionalities Helps avoiding confusion and arguments Helps minimizing the changes
Changes in requirements are expensive. Changing the requirements costs: 3 x as much during the design phase 5-10 x as much during implementation 10-100 x as much after release [Code
Complete, p30]
Why requirements? 2/3 of finished system errors are
requirements and design errors [RG] A careful requirements process doesn’t
mean there will be no changes later Average project experiences about 25%
changes in the requirements This accounts for 70-80% if the rework of
the project [Code Complete, p40] Important to plan for requirements changes
The case of critical applications
Different levels of abstraction
User requirements (abstract) Usually the first attempt for the description of
the requirements Services and constraints of the system In natural language or diagrams Readable by everybody Serve business objectives
System requirements (NOT abstract) Services and constraints of the system in detail Useful for the design and development Precise and cover all cases Structured presentation
Example User requirement: As a user who found a new job
announcement, I want to add a new position to the website so s/he can start working on doing the initial research and apply to it
System requirement: A registered user on the academic jobs website should be able to add a new position listing with the name of the school and academic unit, date of posting, date of expiry, application deadline, and contact and application details. The interaction fails if: the position is already listed, the application deadline is in the past, position announcement is expired, or the contact information is missing. If fails, point mistakes to user and ask the user to fix and resubmit.
Types of requirements Functional requirements
Services the system should provide What the system should do or not in reaction to particular
situations Non-functional requirements
Constraints on the services or functions offered by the system
Examples: Timing constraints (e.g., one semester), constraints on the development process (CASE, language, development method…), standards etc
Domain requirements From the application domain of the system May be functional or non-functional Examples: Medicine, library, physics, chemistry
Note: You can have all of user/system functional/non-functional requirements.
User requirements First attempt to describe functional and non-
functional requirements Understandable by the user
Problems: Lack of clarity - ambiguous language Requirements confusion - functional, non-functional
requirements, design information are not distinguished
Requirements amalgamation – several requirements are defined as a single one
Incompleteness – requirements may be missing Inconsistency – requirements may contradict
themselves
User requirements Guideline to minimize the issues:
Separate requirements – separate the requirements, separate functional and non-functional requirements, requirements must be clearly identified (e.g. by a number)
Include a rationale for each requirement – helps clarify reasoning behind the requirements and may be useful for evaluating potential changes in the requirements
Invent or use a standard form/template Distinguish requirements priorities
Example: MoSCoW (Must, Shall, Could, Want/Will (no TBD)) Avoid technical jargon Testable (write test cases) Deliverables
System requirements Elaborate the user requirements to get
a precise, detailed and complete version of them
Used by designers and developers An important aspect is how to
present/write system requirements Natural language is often used!
The difference between user and system requirements must not be thought as a detail
System requirements Example: If sales for current month are below
target sales, then report is to be printed unless difference between target sales and actual sales is less than half of difference between target sales and actual sales in previous month, or if difference between target sales and actual sales for the current month is less than 5%.
Problems: Difficult to read Ambiguity: sales and actual sales, 5% of what? Incomplete: what if sales are above target sales?
Writing system requirements Natural language (informal requirements)
Reviled by academics But widely practiced: everybody can read them,
finding a better notation is hard Structured natural language
Forms/templates are used to bring some rigor to natural language presentations
Graphical notations Using boxes, arrows… but they mean different things
to different people Formal specification
Based on logic, state machines… Hard to understand for many people
An analogy Archimedes (ca. 250 bc)
Any sphere is equal to 4 times the cone which has its base equal to the greatest circle in the sphere and its height equal to the radius of the sphere.
Today V = 4/3 pi r 3
How is this bit of history relevant for software requirements? Formal is better only if everybody understands it It may take a long time to find a good notation Software requirements is an area of research
Non-functional requirements They can be further categorized into:
Product requirements Product behavior Ex: Timing, performance, memory, reliability,
portability, usability Organizational requirements
Policies and procedures in the customer’s and developer’s organizations
Example: Process requirements, implementation requirements, delivery requirements
External requirements Factors externals to the system and the development
process Example: Interoperability, legislation, ethics
Non-functional requirements may be more critical than functional requirements. (The system may be useless…)
Non-functional requirements
Performancerequirements
Spacerequirements
Usabilityrequirements
Efficiencyrequirements
Reliabilityrequirements
Portabilityrequirements
Interoperabilityrequirements
Ethicalrequirements
Legislativerequirements
Implementationrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Productrequirements
Organizationalrequirements
Externalrequirements
Non-functionalrequirements
Non-functional requirements
It is important to be able to test/verify/check non-functional requirements
Property MeasureSpeed Processed transactions/second
User/Event response timeScreen refresh time
Size K BytesNumber of RAM chips
Ease of use Training timeNumber of help frames
Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability
Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure
Portability Percentage of target dependent statementsNumber of target systems
Requirement engineering
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and systemrequirements
Requirementsdocument
Feasibility study It is done at first to decide whether or not the
project is worthwhile Look at different perspectives:
Market analysis, financial, schedule, technical, resource, legal…
Should make you aware of the risks
Feasibility study Doing the study
Consult information sources: managers, software engineers, end users…
Based on information collection (interviews, surveys, questionnaires…)
Should be short (2-3 weeks)
Feasibility study What if the system wasn’t implemented? What are current process problems? Do technical resources exist? What is the risk associated with the
technology? Is new technology needed? What skills? How will the proposed project help? How does the proposed project contribute to
the overall objectives of the organization? Have the benefits identified with the system
being identified clearly?
Feasibility study What will be the integration problems? What facilities must be supported by the
system? What is the risk associated with cost
and schedule? What are the potential
disadvantages/advantages? Are there legal issues? Are there issues linked with the fact that
this is an offshore project? …
For your project
Any volunteers?
Requirements: functional,non-functional, domain
Feasibility: idea, risks, legal,member training
For your project
Any volunteers?
Requirements: functional,non-functional, domain
Feasibility: idea, risks, legal,member training
For your project
Any volunteers?
Requirements: functional,non-functional, domain
Feasibility: idea, risks, legal,member training
Estimation & Planning
User Stories are the central focus for developersEach User Story should imply an acceptance testComplexity is estimated in Story Points
Arbitrary measure of relative complexity We use modified Fibonacci Sequence (0, 1, 2, 3, 5, 8, 13, 21) Estimates are collaborative to uncover assumptions Based on Staffing we estimate how many Story Points we can
accomplish in a 2 week Iteration (Velocity)
Other Example User Stories*
These were excerpted from http://www.westborosystems.com/2010/02/user-story-examples/ Also see http://agile.csc.ncsu.edu/SEMaterials/tutorials/coffee_maker/ for a great set of examples and
tutorials
Key Points
Cards: physical (or virtual) medium where the story is recordedConversation:Discussion and clarification, modification of the story via communication with the userConfirmation:Tests to verify the user story
I.N.V.E.S.T.
I = independent. Not requiring other features.N = negotiable. Can be excluded, revised, etc.V = valuable. Clearly contributing to product usefulnessE = estimable. Reasonable development estimates can be made from the story.S = small. Stories that are too big tend to be vague and to miss the other points, too.T = testable. Stories need to have a means of verifying functionality.
So how to maintain user stories?
Use online tool: Pivotal Tracker
I To create, assign, and maintain user stories for your project
Mandatory: I will track your progress through it.
We have an academic account, I will send invites to teams.
CS 370, Günay (Emory) Requirements and Feasibility Spring 2014 6 / 9
So how to maintain user stories?
Use online tool: Pivotal Tracker
I To create, assign, and maintain user stories for your project
Mandatory: I will track your progress through it.
We have an academic account, I will send invites to teams.
CS 370, Günay (Emory) Requirements and Feasibility Spring 2014 6 / 9
Demos, Honorable (and Horrible) Mentions
Invited demos:
Hyo Byun � TimeTrack
Maddie Wen & Patrick O'Leary � Forum
Shiyi �Tony� Ying � Dooley wants to know
Ethan Cohen & Paul Kitchell � Petition Creator
Wes Painter � Photoshopped?
Honorable mentions:
Huili Chen � NoContext
Jennifer Ashiru & Sushi R. � Haunted House
Milap Naik & Dave Stess � DogeFortune
Austin Dong & Zeyu Zhang � Calculator
Horrible mentions:
James Ding � Cengiz vs. Django
Meh:
Submitted the tutorial!!!
CS 370, Günay (Emory) Requirements and Feasibility Spring 2014 8 / 9
Demos, Honorable (and Horrible) Mentions
Invited demos:
Hyo Byun � TimeTrack
Maddie Wen & Patrick O'Leary � Forum
Shiyi �Tony� Ying � Dooley wants to know
Ethan Cohen & Paul Kitchell � Petition Creator
Wes Painter � Photoshopped?
Honorable mentions:
Huili Chen � NoContext
Jennifer Ashiru & Sushi R. � Haunted House
Milap Naik & Dave Stess � DogeFortune
Austin Dong & Zeyu Zhang � Calculator
Horrible mentions:
James Ding � Cengiz vs. Django
Meh:
Submitted the tutorial!!!
CS 370, Günay (Emory) Requirements and Feasibility Spring 2014 8 / 9
Demos, Honorable (and Horrible) Mentions
Invited demos:
Hyo Byun � TimeTrack
Maddie Wen & Patrick O'Leary � Forum
Shiyi �Tony� Ying � Dooley wants to know
Ethan Cohen & Paul Kitchell � Petition Creator
Wes Painter � Photoshopped?
Honorable mentions:
Huili Chen � NoContext
Jennifer Ashiru & Sushi R. � Haunted House
Milap Naik & Dave Stess � DogeFortune
Austin Dong & Zeyu Zhang � Calculator
Horrible mentions:
James Ding � Cengiz vs. Django
Meh:
Submitted the tutorial!!!
CS 370, Günay (Emory) Requirements and Feasibility Spring 2014 8 / 9
Demos, Honorable (and Horrible) Mentions
Invited demos:
Hyo Byun � TimeTrack
Maddie Wen & Patrick O'Leary � Forum
Shiyi �Tony� Ying � Dooley wants to know
Ethan Cohen & Paul Kitchell � Petition Creator
Wes Painter � Photoshopped?
Honorable mentions:
Huili Chen � NoContext
Jennifer Ashiru & Sushi R. � Haunted House
Milap Naik & Dave Stess � DogeFortune
Austin Dong & Zeyu Zhang � Calculator
Horrible mentions:
James Ding � Cengiz vs. Django
Meh:
Submitted the tutorial!!!CS 370, Günay (Emory) Requirements and Feasibility Spring 2014 8 / 9
Voting for WebIdol
Do not dial 800 numbers!
I will post a poll on Piazza now
Voting until class on Thursday
CS 370, Günay (Emory) Requirements and Feasibility Spring 2014 9 / 9