Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
XP Requirements Engineering-Software Engineering-Lecture Slides, Slides of Software Engineering
Software engineering is about the development and application of processes and tools for managing the complexities inherent in creating high quality software systems. It introduces the fundamental software engineering concepts and terminology. This lecture includes: Software, Requirement, Specification, XP, Agile, Programming, Analysis, Elicitation, Stakeholders, Maintenance, Domain
Typology: Slides
1 / 29
Related documents
Partial preview of the text
Download XP Requirements Engineering-Software Engineering-Lecture Slides and more Slides Software Engineering in PDF only on Docsity!
1
Software RequirementsSpecificationSRS in XP
“Dilbert” on Extreme and AgileProgramming
CS
4-
Requirements Analysis
Understanding
the customer’s
requirements for a softwaresystem
how to do it
Requirements analysis
Sometimes called
requirements elicitation
or
requirements discovery
Involves
technical staff
working with
customers
to
find out about the application domain, the servicesthat the system should provide and the system’soperational constraints
May involve end-users, managers, engineersinvolved in maintenance, domain experts, tradeunions, etc. These are called
stakeholders
Problems of requirements analysis
Stakeholders don’t know
what they really want
Stakeholders express requirements in their
own
terms
Different stakeholders may have
conflicting
requirements
Organisational and political factors
may influence
the system requirements
The
requirements change
during the analysis
process. New stakeholders may emerge
The requirements analysis process
Requirements
validation
Domain
understanding
Prioritization
Requirements
collection
Conflict
resolution
Classification
Requir ementsdefinition and
specification
Process
entry
CS
4-
Requirements
Requirements should be
specific, so you can tell whether you met them.
precise as necessary, but no more
Functional requirements
inputs, outputs, and the relations between them
in theory, can specify completely
Non-functional requirements
hard to specify, can’t specify completely
•scalability
•maintainability
•portability
•...
•security
•reliability•efficiency
•usability
CS
4-
Functional requirements
Inputs, outputs, and the relationship
between them
Use Cases
Formats, standard interfaces
Business rules and complex formula
CS
4-
Functional requirements
Command language
The “get” command will transfer ...
Web pages
Input forms, dynamic pages
Connections to other systems
Files, sockets, XML, …
Reports, displays
Functional requirements
Requirement: a desired relationship among
phenomena
of the environment of a system, to be brought about bythe hardware/software
machine that will be constructed
and installed in the environment.
A specification describes machine behavior
sufficient to
achieve the requirement.
A specification is a restricted kind of requirement
Lathe Operator
Machine
RequiredBehavior
of lathe
Specification
Requirements
Functional requirements
Requirements
define necessary objectives e.g.
software must handle error states reasonably and effectively,and provide explicit feedback to the users.
Specifications Define How to Meet The Objectives
list out all possible error states for a certain form, along with allof the error messages that should be displayed to the user.
CS
4-
Non-functional requirements
Performance
Must answer a query in 3 seconds
Usability
New user must be able to finish buying a book in 15 minutes
90% of users must say they like interface
Maintainability
New programmers should be able to fix first bug in two weeks on the job
CS
4-
Nonfunctional requirements
Technology
Must use Java
Business
Must get it finished in 1 year spending less
than $1,000,000.
XP Requirements: ReleasePlanning
Release Planning
Happens in the beginning of every project
Made up of 2 phases: Exploration + Planning Game
Each project divided up into 1+ releases
Each release must
Be small
Must deliver enough features to be of business value
Consist of a collection of user stories to provide features
User Stories
User story is a short
description of whatthe business orcustomer wants thesoftware to do,written by thecustomer in thecustomerterminology withouttechno-syntax.
User Stories Index Cards
Usually written on indexcards because easy to
understand
Pass around
Tear up
Prioritize
One and only onebusiness feature
Written by & focus oncustomer
Avoid details of specifictechnology, data baselayout, and algorithms
Poor User Stories
Too vague and hardto
Estimate
Test
Defines implementationdetails
Customer doesn’t careabout Tomcat orDreamweaver
Splitting of Stories
More than onebusiness feature
Search and
Selection functionality
Split
Planning Game Example(From Textbook)
Northwind Inc Business Problem
Large reseller of food & beverage products.
Product sales over direct-mail catalogs.
Processing of ordersdone over the phone
from initial input of the order to
shipment and delivery of the order
3-
Create a Web presence that allows customers to self-order
Northwind products and
track the status of their orders all the way through to shipment
3-
User Stories for Northwind
Quick High-Level Design Flow
3-21
User Story Estimating&Planning Game
Estimating
Estimates are in Story Points
1 story point = 1 ideal day
Planning Game
Prioritization of User Stories
Priority is from 1 to
n, not high, medium, low.
Velocity Determination
(
No. of Devs/Load Factor
✕
Iteration Length in Business Days
E.g. for
8 developers
2-week iteration (10 business days)
load factor=4 (as developers spend time not coding (meetings, email,pair programming)
Iteration velocity (#story pts team can complete)= (8/4 X 10) = 20
User Story Estimating&Planning Game
So, using the previous calculation of 20 ideal days as theiteration team velocity, for six development iterations,the velocity calculation is as follows:
6
✕
20 = 120
The result is 120 ideal days in the release.
Planning Game
Planning happens once at the start of each iteration
Plan for just one iteration at a time
Planning game is the main interface between customerand development team
How it works
Customer provides all the story cards that have beenwritten
Developers write on each card an estimate of how long itwill take to implement
Developers provide an estimate of available developers Xtime (= “velocity”)
Customer chooses stories by priority to fill the availabletime
Individual’s Velocity
Here is the formula for calculating the velocity of anindividual:
No. of Hours in Workday
✕
Length of Iteration/Load
Factor (Truncated) = Individual Velocity
The length of the iteration is in business days. The loadfactor accounts for other, non development activities. Theindividual velocity is in ideal hours.
For example, the following uses an 8-hour workday with a2-week iteration and a load factor of 4:
8
✕
10/4 = 20
The result is 20 ideal hours in the iteration for thedeveloper.