Software Requirements and Engineering Tarbut v Torah Howard

Software Requirements and Engineering
Tarbut v Torah
Howard Rosenthal
Jan. 2015
Purpose
 Describe how programs are segmented
 Describe three development approaches
 Waterfall
 Spiral
 Agile
2
Requirements
 Requirements are developed through a combined process of
decomposition and modelling
 Decomposition is an art as much as a science
 Develop modules that are easily testable
 Develop a decomposition scheme that is easily integratable
 Modeling and modeling tools help as develop requirements
detail at each level of decomposition
 Software often has security, performance and reliability
requirements
 When software (even homework) is delivered it should be done
to specifications
 You don’t change specifications with the agreement of the
stakeholders
 Software systems are often part of bigger integrated systems
3
Decomposition
Top Level Description of System
– Space Station
System Specification
Segment
Specification
Second Level Decomposition
(On Board)
Third Level Decomposition –
Integrates into deliverable
segments
Fourth Level – Divides HW and
SW Deliverables that will be
further specified
Fifth Level – Further
Decomposition and some
Design Specification
Subsystem
(Communications)
Software
Configuration Item
(Routing SW)
Routing Algorithms
000
000
000
Segment
Specification
000
Subsystem (Sensors)
(Ground)
Subsystem
(Planning)
000
Subsystem (Data
Archiving)
Hardware
Configuration Item
(Router)
Queue Manager
4
Waterfall Methodology
5
Waterfall Methodology Description
 Waterfall is a linear approach to software development. In this
methodology, the sequence of events is something like:







Gather and document requirements
Design
Code and unit test
Perform system testing
Perform user acceptance testing (UAT)
Fix any issues
Deliver the finished product
 In a true Waterfall development project, each of these represents a
distinct stage of software development, and each stage generally
finishes before the next one can begin.
 There is also typically a stage gate between each; for example,
requirements must be reviewed and approved by the customer before
design can begin.
6
Pros of The Waterfall Model
 Developers and customers agree on what will be delivered early in the development
lifecycle. This makes planning and designing more straightforward.
 Progress is more easily measured, as the full scope of the work is known in advance.
 Throughout the development effort, it’s possible for various members of the team to be
involved or to continue with other work, depending on the active phase of the project.
For example, business analysts can learn about and document what needs to be done,
while the developers are working on other projects. Testers can prepare test scripts from
requirements documentation while coding is underway.
 Except for reviews, approvals, status meetings, etc., a customer presence is not strictly
required after the requirements phase.
 Because design is completed early in the development lifecycle, this approach lends itself
to projects where multiple software components must be designed (sometimes in
parallel) for integration with external systems.
 Finally, the software can be designed completely and more carefully, based upon a more
complete understanding of all software deliverables.
 This provides a better software design with less likelihood of the “piecemeal effect,” a
development phenomenon that can occur as pieces of code are defined and subsequently
added to an application where they may or may not fit well.
Despite the statements above, expect changes
to requirements in any long-term program
7
Issues With the Waterfall Model
 One area which almost always falls short is the effectiveness of requirements.
 Gathering and documenting requirements in a way that is meaningful to a
customer is the most difficult part of software development, in my opinion.
 Customers are sometimes intimidated by details, and specific details, provided
early in the project, are required with this approach.
 Customers are not always able to visualize an application from a requirements
document.
 Wireframes and mockups can help, but there’s no question that most end users
have some difficulty putting these elements together with written requirements
to arrive at a good picture of what they will be getting.
 Another potential drawback of pure Waterfall development is the possibility
that the customer will be dissatisfied with their delivered software product.
 As all deliverables are based upon documented requirements, a customer may
not see what will be delivered until it’s almost finished. By that time, changes
can be difficult (and costly) to implement.
 This problem is often addressed through intermediate design reviews and Joint
Application Development sessions where representative stakeholders review
the user interfaces and capabilities
8
Spiral Model
9
Spiral Methodology Description

The Spiral Life Cycle Model is a type of iterative software development model which is generally
implemented in high risk projects.



Each loop in a spiral represents a development phase (and we can have any number of loops according
to the project). Each loop has four sections or quadrants :





Determine the objectives, alternatives and constraints.
Risk analysis and evaluation of alternatives. Here we try to find which other approaches can be implemented in
order to fulfill the identified constraints.
Execution of that phase of development. In this phase we develop the planned product. Testing is also done. In
order to do development, waterfall or incremental approach can be implemented.
Planning the next phase. Here we review the progress and judge it considering all parameters. Issues which need
to be resolved are identified in this phase and necessary steps are taken.
Subsequent loops of spiral model involve similar phases.


First proposed by Boehm.
In this system development method, we combine the features of both the waterfall model and prototype model.
Large, expensive or complicated projects use this type of life cycle. If at any point of time one feels the risk
involved in the project is a lot more than anticipated, one can abort it. Reviews at different phases can be done by
an in-house person or by an external client.
The Spiral model is also called as meta-model because in a way it comprises of other models of SDLC.
Both waterfall and prototype models are used in it. Here we do software development systematically
over the loops (adhering to waterfall approach) and at the same time we make a prototype and show
it to user after completion of various phase (just in case of prototype model). This way we are able to
reduce risks as well as follow systematic approach.
10
Spiral Modeling Advantages
 High amount of risk analysis hence, avoidance of Risk




is enhanced.
Good for large and mission-critical projects.
Strong approval and documentation control.
Additional Functionality can be added at a later date.
Software is produced early in the software life cycle.
11
Issues With The Spiral Model
 Can be a costly model to use.
 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk
analysis phase.
 Doesn’t work well for smaller projects.
12
The Agile Process
13
The Agile Process is Very
Responsive To Immediate Needs
14
Agile Methodology Description
 Agile is an iterative, team-based approach to development.
 This approach emphasizes the rapid delivery of an application in
complete functional components. Rather than creating tasks and
schedules, all time is “time-boxed” into phases called “sprints.”

Each sprint has a defined duration (usually in weeks) with a running list
of deliverables, planned one sprint in advance.
 Deliverables are prioritized by business value as determined by the
customer.
 If all planned work for the sprint cannot be completed, work is
reprioritized and the information is used for future sprint planning.
 As work is completed during each sprint, it is continuously
reviewed and evaluated by the customer, who may be considered
the most critical member of the Agile team.
 As a result, Agile relies on a very high level of customer involvement
throughout the project.
15
Agile Programming Advantages
 The customer has frequent and early opportunities to
see the work being delivered, and to make decisions
and changes throughout the development project.
 The customer gains a strong sense of ownership by
working extensively and directly with the project team
throughout the project.
 If time to market for a specific application is a concern,
Agile can more quickly produce a basic version of
working software.
 Development is often more user-focused, likely a result
of more and frequent direction from the customer.
16
Issues With Agile Programming
 The very high degree of customer involvement, while great for the project, may present
problems for some customers who simply may not have the time or interest for this type
of participation.
 Agile works best when members of the development team are completely dedicated to
the project.
 Because Agile focuses on time-boxed delivery and frequent reprioritization, it’s possible
that some items set for delivery will not be completed within the allotted timeframe.
 Additional sprints (beyond those initially planned) may be needed, adding to the project
cost. In addition, customer involvement often leads to additional features requested
throughout the project. Again, this can add to the overall time and cost of the
implementation. – This is known as requirements creep!!
 The close working relationships in an Agile project are easiest to manage when the team
members are located in the same physical space, which is not always possible. However,
there are a variety of ways to handle this issue, such as webcams, collaboration tools, etc.
 The iterative nature of Agile development may lead to a reduction in overall system
quality, as there is less emphasis on understanding the finished system as a whole early in
the project. This becomes more pronounced in larger-scale implementations, or with
systems that include a high level of integration.
17