Module: Software Engineering Overview

Software is more than just a program code. A program is an executable

code, which serves some computational purpose. Software is considered to
be a collection of executable programming code, associated libraries and
documentation. Software, when made for a specific requirement is called
software product.

Engineering on the other hand, is all about developing products, using well-
defined, scientific principles and methods.

The term software engineering is the product of two words, software,

and engineering.

The software is a collection of integrated programs.

Software consists of carefully organized instructions and code written by

developers on any of various particular computer languages.

Computer programs and related documentation such as requirements, design

models, and user manuals.

Engineering is the application of scientific and practical knowledge

to invent, design, build, maintain, and improve frameworks,
processes, etc.

Software engineering is a discipline within the field of computer science that

focuses on the systematic design, development, testing, deployment, and
maintenance of software systems. It involves applying engineering principles to
software development to ensure that software projects are completed on time,
within budget, and with the desired level of quality.The outcome of software
engineering is an efficient and reliable software product.

IEEE defines software engineering as:

The application of a systematic, disciplined, quantifiable approach to the development,

operation and maintenance of software; that is, the application of engineering to
software.

1
Software Evolution Laws
Lehman has given laws for software evolution. He divided the software into
three different categories:

• S-type (static-type) - This is software, which works strictly according to

defined specifications and solutions. The solution and the method to achieve it,
both are immediately understood before coding. The s-type software is least
subjected to changes hence this is the simplest of all. For example, a calculator
program for mathematical computation.

• P-type (practical-type) - This is a software with a collection of procedures.

This is defined by exactly what procedures can do. In this software, the
specifications can be described but the solution is not obvious instantly. For
example, gaming software.

• E-type (embedded-type) - This software works closely with the requirements

of the real-world environment. This software has a high degree of evolution as
there are various changes in laws, taxes, etc. in real-world situations. For
example, Online trading software.

Characteristics of good software

A software product can be judged by what it offers and how well it can be
used. This software must satisfy on the following grounds:

• Operational

• Transitional

• Maintenance

Well-engineered and crafted software is expected to have the following

characteristics:

Operational
This tells us how well software works in operations. It can be measured on:

• Budget

• Usability

2
 • Efficiency

• Correctness

• Functionality

• Dependability

• Security

• Safety

Transitional
This aspect is important when the software is moved from one platform to
another:

• Portability

• Interoperability

• Reusability

• Adaptability

Maintenance
This aspect briefs about how well a software has the capabilities to maintain
itself in the ever-changing environment:

• Modularity
• Maintainability
• Flexibility
• Scalability
In short, Software engineering is a branch of computer science, which uses
well-defined engineering concepts required to produce efficient, durable,
scalable, in-budget and on-time software products.

Characteristics of a good software engineer

The features that good software engineers should possess are as
follows:

Exposure to systematic methods, i.e., familiarity with software engineering

principles.

3
Good technical knowledge of the project range (Domain knowledge).

Good programming abilities.

Good communication skills. These skills comprise of oral, written, and

interpersonal skills.

High motivation.

Sound knowledge of fundamentals of computer science.

Intelligence.

Ability to work in a team

Discipline, etc.

Importance of Software Engineering

The importance of Software engineering is as follows:

1. Reduces complexity: Big software is always complicated and

challenging to progress. Software engineering has a great solution to
reduce the complication of any project. Software engineering divides big
problems into various small issues. And then start solving each small

4
 issue one by one. All these small problems are solved independently to
each other.
2. To minimize software cost: Software needs a lot of hardwork and
software engineers are highly paid experts. A lot of manpower is
required to develop software with a large number of codes. But in
software engineering, programmers project everything and decrease all
those things that are not needed. In turn, the cost for software
productions becomes less as compared to any software that does not
use software engineering method.
3. To decrease time: Anything that is not made according to the project
always wastes time. And if you are making great software, then you
may need to run many codes to get the definitive running code. This is
a very time-consuming procedure, and if it is not well handled, then this
can take a lot of time. So if you are making your software according to
the software engineering method, then it will decrease a lot of time.
4. Handling big projects: Big projects are not done in a couple of days,
and they need lots of patience, planning, and management. And to
invest six and seven months of any company, it requires heaps of
planning, direction, testing, and maintenance. No one can say that he
has given four months of a company to the task, and the project is still
in its first stage. Because the company has provided many resources to
the plan and it should be completed. So to handle a big project without
any problem, the company has to go for a software engineering method.
5. Reliable software: Software should be secure, means if you have
delivered the software, then it should work for at least its given time or
subscription. And if any bugs come in the software, the company is
responsible for solving all these bugs. Because in software engineering,
testing and maintenance are given, so there is no worry of its reliability.
6. Effectiveness: Effectiveness comes if anything has made according to
the standards. Software standards are the big target of companies to
make it more effective. So Software becomes more effective in the act
with the help of software engineering.

History of Software Engineering

The history of software engineering is a journey that spans several
decades, marked by significant developments, methodologies, and
practices. Here's an overview of the key milestones in the history of
software engineering:

5
 1950s-1960s: Early Days and Software Crisis

The concept of software engineering began to take shape as computers

became more widespread. Early software development was ad hoc, with
little emphasis on structured processes or documentation. The term
"software crisis" emerged as software projects faced challenges related
to schedule delays, budget overruns, and poor quality.

1960s-1970s: Structured Programming and Software Engineering

Emergence

Structured programming principles, such as modularization and control

flow, were introduced to improve software quality.
The idea of systematic software development gained traction, leading to
the emergence of software engineering as a formal discipline.

In 1968, NATO held a conference on software engineering, helping to

establish foundational principles.

1970s-1980s: Waterfall Model and Early Methodologies

The Waterfall model, a linear approach to software development,

became popular. It involved sequential phases like requirements,
design, implementation, testing, and maintenance.
The concept of software development methodologies evolved, leading
to the creation of methods like the Structured Systems Analysis and
Design Method (SSADM) and Yourdon's methodologies.

1980s-1990s: Object-Oriented Programming and Agile

Movement

Object-oriented programming (OOP) gained prominence, encouraging

modular design and reusable code.
The Agile movement emerged in the early 2000s as a response to rigid
methodologies. Agile methodologies like Scrum and Extreme
Programming (XP) prioritized collaboration, flexibility, and incremental
development.

1990s-2000s: Rapid Technological Advancements

6
 The growth of the internet and the rise of e-commerce led to increased
demand for web applications and software.DevOps practices emerged,
emphasizing collaboration between development and operations teams
to streamline software delivery.

2010s-Present: Cloud Computing, Continuous Integration, Agile

and DevOps

Cloud computing revolutionized software deployment and scalability.

Continuous Integration/Continuous Deployment (CI/CD) became
integral to software development, enabling rapid and automated testing
and deployment.
DevOps practices continued to evolve, focusing on cultural changes,
automation, and collaboration.

Current and Future Trends: AI, Machine Learning, and Beyond

Artificial intelligence (AI) and machine learning (ML) are being

integrated into software systems, enabling automation, data analysis,
and predictive capabilities. Emphasis on user experience (UX) design
and user-centered development has grown. Cybersecurity and software
sustainability have become critical concerns.
Throughout its history, software engineering has seen the development
of various methodologies and practices to address the challenges posed
by rapidly evolving technology and changing user needs. The field
continues to adapt to new paradigms, tools, and techniques, shaping
the way software is developed, tested, and maintained.

Key Concepts in Software Engineering:

Software Development Life Cycle (SDLC): This is the process that

guides the development of software from its initial conception to its final
deployment and maintenance. The most common SDLC models include
Waterfall, Agile, Scrum, and DevOps.

Requirements Analysis: In this phase, software engineers work

closely with stakeholders to understand their needs and define the
functional and non-functional requirements of the software system.

7
 Design: Based on the requirements, the software system's architecture,
components, and interfaces are designed. This includes both high-level
architectural design and low-level detailed design.

Implementation: During this phase, the actual coding of the software

takes place. Programmers write code according to the design
specifications, following best practices and coding standards.

Testing: Software testing is crucial to identify and fix bugs, ensure the
software works as intended, and meets the defined requirements.
Testing includes unit testing, integration testing, system testing, and
more.

Deployment: Once the software is thoroughly tested and deemed

ready, it is deployed to the production environment. This phase involves
configuring the software, setting up servers, and making it available to
users.

Maintenance: After deployment, the software requires ongoing

maintenance, which includes fixing bugs, adding new features, and
adapting to changes in the environment or user requirements.

Version Control: Version control systems like Git help manage changes
to the source code, allowing multiple developers to collaborate efficiently
and track the evolution of the software over time.

Software Quality Assurance: Ensuring the quality of the software

through processes like code reviews, testing automation, and adherence
to coding standards.

Documentation: Proper documentation is essential for understanding

the software's design, functionality, and usage. It aids in maintenance,
troubleshooting, and knowledge transfer.

Software Development Methodologies:

Waterfall: A linear approach where each phase is completed before

moving to the next.

Agile: An iterative and flexible approach that emphasizes collaboration,

adaptability, and customer feedback.

8
 Scrum: A specific Agile framework that organizes work into time-bound
iterations called sprints.

DevOps: Focuses on collaboration between development and IT

operations teams to automate and streamline the software delivery
process.

Exercises

1. A legacy system refers to outdated application software that is used instead of

available upgraded versions.
a. True b. False
2. What is the main aim of Software engineering?
a. Reliable software
b. Cost-effective software
c. Reliable & cost-effective software
d. None of the above
3. Lehman divided software into three categories. In which category software works
strictly according to defined specifications and solutions.
a. Static type
b. Embedded-type
c. Practical-type
d. None of the above

References:

• Fundamental of Software Engineering, Dr. Rajib Mall.

• www.computer.org/education

9
Software Engineering Code of Ethics and Professional Practice (Short
Version)

PREAMBLE
The short version of the code summarizes aspirations at a high level of the
abstraction; the clauses that are included in the full version give examples
and details of how these aspirations change the way we act as software
engineering professionals. Without the aspirations, the details can become
legalistic and tedious; without the details, the aspirations can become high
sounding but empty; together, the aspirations and the details form a
cohesive code.

Software engineers shall commit themselves to making the analysis,

specification, design, development, testing and maintenance of software a
beneficial and respected profession. In accordance with their commitment to
the health, safety and welfare of the public, software engineers shall adhere
to the following Eight Principles:

1. PUBLIC - Software engineers shall act consistently with the public

interest.

2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is

in the best interests of their client and employer consistent with the public
interest.

3. PRODUCT - Software engineers shall ensure that their products and

related modifications meet the highest professional standards possible.

4. JUDGMENT - Software engineers shall maintain integrity and

independence in their professional judgment.

5. MANAGEMENT - Software engineering managers and leaders shall

subscribe to and promote an ethical approach to the management of
software development and maintenance.

6. PROFESSION - Software engineers shall advance the integrity and

reputation of the profession consistent with the public interest.
7. COLLEAGUES - Software engineers shall be fair to and supportive of their
colleagues.

8. SELF - Software engineers shall participate in lifelong learning regarding

the practice of their profession and shall promote an ethical approach to the
practice of the profession.
Software Process Models
 Objectives
• The intent of this module is to discuss various
software Life Cycle/ Process models by professional
software developers to manage large-scale projects.
At the end of this module the student will be able to:
– Explain what is a life cycle model and why we use.
– Identify the different phases of the Waterfall model.
– Identify various other process model and their
application.
– Identify the activities undertaken in each phase.
– Identify the shortcomings of the models.
– Identify the phase-entry and phase-exit criteria for
each phase.
Software Development Process
Model
• Process model provides a generic framework
that can be tailored to a specific project.
• Systematic process to develop high quality
software.
• Normally, a process model covers the entire
lifetime of a product.
• Software process models are frequently called
life cycle models and terms are interchangeable.
 Software Life Cycle
● Software life cycle represents the Series of
identifiable stages that a software product
undergoes during its life time:
● Feasibility study

● Requirements analysis and specification

● Design
● Coding
● Testing
● Maintenance.
 Why Model Life Cycle ?
• Primary advantage of adhering to a life cycle
model:
– helps development of software in a systematic and
disciplined manner.
• Provides a common software development
framework within and across projects.
• Improve efficiency and reduce risks.
• Facilitate communication among
stakeholders.
 Why Model Life Cycle ?
● When a program is developed by a single
programmer ---
– he has the freedom to decide his exact steps.

● When a software product is being developed by

a team:
– there must be a precise understanding among
team members as to when to do what,
– otherwise it would lead to chaos and project
failure.
Phases of SDLC
 Phase Exit and Entry
● A life cycle model:
– defines entry and exit criteria for every
phase.
– A phase is considered to be complete:
● only when all its exit criteria are satisfied.
– For example phase exit criteria for the
software requirements specification phase is
• Software Requirements Specification (SRS)
document is complete, reviewed, and approved by
the customer.
 Phase Exit and Entry
• A phase can start:
– only if its phase-entry criteria have been
satisfied.
• Helps to software project manager to monitor the
project progress.
• If phase entry and exit are not clearly specified,
it is hard to measure the progress of the
software development process (99% syndrome)
 Why Need Different models?
• One model everyone can follow?
– Every Team, projects and organization
is different
– Constraints on project is different
– One model may fit in one situation and
not suitable for other
 Classification of Models?
• Choosing right model is a challenge.
– Predictive vs. Adaptive
– Incremental vs. Iterative
 Predictive vs. Adaptive
• Predictive
– Good understanding of the requirements of
the software
– After requirements follow various lifecycle
stages like design implementation , testing
etc.
– Get the product in one go and generally
changes are not desired during development
process,
 Predictive vs. Adaptive
• Adaptive
– Client/customers have rough idea about what
they want?
– Developer start with basic idea and develop
small version or prototype
– Customer and developer use the product and
based on the feedback refine the requirements
and product (Adopt based on feedback)
– At the end the product you will get may be not
originally think fulfill customer requirements
 Incremental vs Iterative
Incremental model Iterative model
– Fair idea what to build • Not clear about final product
– Do not build the product • Building on top of existing
in one go product and enhancement
exists but In incremental
– Build the product in
model you just breaking
increments (stages) product into small pieces.
– Useful when organization• Incremental model may be
benefited in intermediate predictive or adaptive.
outcome or if they are
going to change later
increments based on
feedback.
 Life Cycle Models
● Many life cycle models have been proposed.
● We will confine our attention to a few important
and commonly used models.
– Waterfall model
– Prototyping,
– Evolutionary/Incremental
– Spiral model
– RAD model
– Unified Process
– Agile methods, extreme programming (XP)….
 Waterfall Model
• A sequential model of non-overlapping activities
• Waterfall model divides life cycle into phases:
– feasibility study,
– requirements analysis and specification,
– design,
– coding and unit testing,
– integration and system testing,
– maintenance.
Classical Waterfall Model

Requirement Analysis

Design Development
Phases
Coding

Testing

Maintenance

Project Management
Relative Efforts to Phases
 Feasibility Study
• Main aim of feasibility study is to determine whether
developing the product
– financially worthwhile
– technically feasible.
• First roughly understand what the customer wants:
– different data which would be input to the system,
– processing needed on these data,
– output data to be produced by the system,
– various constraints on the behavior of the system.
 Feasibility Study
• The outputs of the feasibility research are:
– Abstract problem definition
– Formulation of the different solution strategies
– Analysis of alternative solution strategies
 Requirements Analysis and
Specification
• Aim of this phase are:
– understand the exact requirements of
the customer,
– document them properly.
• Consists of two distinct activities:
– requirements gathering and analysis
– requirements specification.
 Requirements Analysis and
Specification
• Client requirements are filled into Software
Requirement Specification (SRS)
document
• Engineers doing requirements analysis
and specification:
– are designated as analysts
 Design
• Transform requirements in the SRS
document into a possible implementation
• Using either Traditional or Object oriented
approaches.
• During design software architecture is
derived from the SRS document.
Implementation (Coding and Unit
Testing)
• Implementation phase translate software
design into source code.
• During the implementation phase:
– each module of the design is coded
• follows the company’s coding standard
– Commenting , variable naming … etc

– each module is unit tested

• tested independently as a stand alone unit,
and debugged,
 Integration and System Testing

•Modules are not

integrated in one shot
–Incrementally over
number of steps
–Keep testing the
increment of modules
–Finally, a full system
testing
–Make sure it complies to
SRS
–Alpha, beta, and
acceptance testing
 Maintenance
• Development and maintenance has 40:60 ratio
• Maintenance involves:
– Correcting and fixing bugs discovered after software
submission (corrective maintenance)
– Optimizing and adding more functionalities to the
system, documentation changes, efficiency
improvements (perfective maintenance)
– Porting the software to work in a new environment
or a system (adaptive maintenance)
 Waterfall Model
• Iterative waterfall model introduces feedback
paths to the previous phases for each
process phase
• Conduct reviews after each milestone
• Feedback paths in classical waterfall model
desirable to detect errors in the same phase
• Principle of detecting errors as close to their
points of introduction as possible: phase
containment errors
 Waterfall model
• How phase containment errors be
achieved?
– Conduct reviews after every milestone
• Iterative waterfall model is by far the most widely
used model.
– Almost every other model is derived from the waterfall
model.
• To achieve a better efficiency and performance, it
is hard to follow it
– Creates “Blocking States” where the advanced phase
team members need to wait for the previous states to
finish.
 Waterfall model problems
• Difficulty of accommodating change after the process
is underway. One phase has to be complete before
moving onto the next phase.
• Inflexible partitioning of the project into distinct
stages makes it difficult to respond to changing
customer requirements.
• Heavy documentation
• Few business systems have stable requirements in the
early stage.
• Difficult and expensive to change decisions
"swimming upstream”.
 Waterfall Model (Advantages)
• Easy to understand and implement.
• This staged development cycle enforces discipline.
• Fits for other engineering process models: Civil,
Mechanical etc.
• Identify deliverables and milestones.
• Works well on mature products.
 Waterfall model (Application)
• This model is appropriate when the
requirements are well-understood and
changes will be fairly limited during the
design process.
• Constrained enhancement of a existing
systems
• Straightforward implementation of a
numerical calculation or business rule
 V Model
• Also called
verification and
validation model
• An extension of the
waterfall model and
is based on the
association of a
testing phase for
each corresponding
development stage.
 V Model
• Some of the most suitable scenarios to
use the V-Model application:
– Requirements are well defined, clearly
documented and fixed.
– Product definition is stable.
– Technology is not dynamic and is well
understood by the project team.
– There are no ambiguous or undefined
requirements.
 Incremental Model
• Builds in parts, multiple mini waterfall
• May overlap
• Can use different model for each
increment
• In a scale of predative and adaptive this
model is somewhere in between depend
on how much feedback you applied from
one feedback to another.
• Also called evolutionary model
 Incremental Model

• Successive version of the product

– A new release may include new
functionality:
• also existing functionality in the current release
might have been enhanced.

A A
 Advantages of Incremental Model
• Deliver value to customer earlier
• Apply feedback for future development to
deliver better value
• Reduces chances of errors in final product
• Useful in the situation when staffing is
unavailable for complete implementation by
the business deadline established for the
project
• Planned to manage technical risks.
• Total cost of project is distributed.
 Disadvantages of Incremental Model
● Often, difficult to subdivide problems into
functional units:
• Model requires well defined project planning
schedule to distribute the work properly.
• You don’t know all the requirements upfront
may be end up with doing some extra work.
• Changes may change the cost.
• Well define interfaces are required to
connect modules developed with each
phase.
 Quiz
• Which of the two is the software
development model that can better
respond to changes in the requirements?
a. Waterfall model
b. Agile Model
 Prototyping Model
• Prototyping is defined as the process of
developing a working replication of a product or
system that has to be engineered.
• Before starting actual development,
– a working prototype of the system should first be built
with:
• limited functional capabilities,
• low reliability,
• inefficient performance.
Prototype: a system which is incomplete and then
modifying and augmenting it as the user
requirements become clear
 Prototyping Model cont…
● Start with approximate requirements.
● Carry out a quick design.
● Prototype model is built using several short-
cuts:
– Short-cuts might involve using inefficient,
inaccurate, or dummy functions.
● A function may use a table look-up rather than
performing the actual computations.
 Prototyping Model cont…
● The developed prototype is submitted to the
customer for his evaluation:
– Based on the user feedback, requirements are
refined.
– This cycle continues until the user approves the
prototype.
● The actual system is developed using the
classical waterfall approach.
 Prototyping Model cont…
Build Prototype

Requirements Customer Customer

Quick Design Evaluation of satisfied Design
Gathering Prototype

Refine Implement
Requirements

Test

Maintain

44
 Reasons for developing a
Prototype
• This model is recommended when the customers do not
know the exact project requirements beforehand.
• Illustrate to the customer:
– input data formats, messages, reports, or interactive
dialogs.
• Examine technical issues associated with product
development:
– Often major design decisions depend on issues like:
• response time of a hardware controller,
• efficiency of a sorting algorithm, etc.
 Reasons for developing a
Prototype
• The third reason for developing a
prototype is:
– it is impossible to ``get it right'' the first
time,
– we must plan to throw away the first
product
• if we want to develop a good product
 Types of Prototype Model
• Exploratory Development Prototype model
– Objective is to work with the user to explore their
requirements and deliver a final system.
– Starts with the part of the system that re
understood and then evolve as the user proposes
new features.
• Throw away Prototype model
– Objective is to understand the user requirements
and develop a better requirements definition for
the system.
 Prototyping Problems
• No. of iteration should be under control
• Developer often makes implementation
compromises in order to get a prototype
working quickly.
– Inappropriate operating system or
programming language may be used simply
because it is available and known
• If end user/client is not satisfied with initial
prototype, he may loose interest in the
project.
 Prototyping Problems
• Requires extensive customer collaboration
– Costs customer time/money
– Needs committed customers
– May be too customer specific, no broad
market
• Difficult to know how long project will last.
 Quiz
Which of the options is correct for the prototyping
model of software development?
a. For projects with large development teams.
b.. When requirements are well defined.
c. When a customer cannot define requirements
clearly.
d. both a & b
e. All of the above
 Case Study
A startup is developing a new mobile application for
language learning. The founders have a basic idea of the
features they want but are open to exploration and
feedback from potential users.
Questions:
1.Explain how the Prototype model could be utilized in the development
of the language learning mobile application.
2.What are the main benefits of using a Prototype model in a project
like this?
3.Discuss the challenges that might arise when using prototypes,
especially in terms of managing client expectations.
4.Can you describe a scenario where the Prototype model might not be
the best fit for a project?
Software Development
Process Models Cont…
 Spiral Model
● Proposed by Boehm in 1988.
● combines elements of both waterfall and iterative
development models.
● Cyclic in nature.
● Reason: traditional software life cycle models do not
deal sufficiently with the uncertainty.
● Boehm tried to incorporate the “project risk” factor
into a life cycle model.
● Waterfall model + risk analysis & Management +
support & management processes.
 Key Characteristics
• Iterative Development: The project passes
through a set of spirals (phases) iteratively.
• Risk Management: Each iteration focuses on
identifying and mitigating risks.
• Prototyping: It allows for building prototypes at
each phase to evaluate risks.
• Flexible and Adaptable: Requirements can
evolve through iterations.
 Phases in Spiral Model
• Planning/Objective defined: Requirements are
gathered, and project goals are defined.
• Risk Analysis: Possible risks are identified, and
solutions or workarounds are planned.
• Engineering: Actual development of the
software based on the requirements and risk
analysis.
• Evaluation: The software is evaluated by the
customer, and feedback is collected for the next
iteration.
Spiral Model cont…
• Each phase of the
Spiral Model is
divided into four
quadrants:
– Objectives
determination and
identify alternative
solutions
– Identify and resolve
Risks:
– Develop the next
version of the
Product:
– Review and plan for
the next Phase:
– First Quadrant: Planning (objective setting,
Constraints, & alternative solutions)
● Objectives such as performance, functionality, ability to
accommodate change, HW/SW interface, and critical
success factors are identified.
● Alternative means implementation of the product or
portion of the product by build reuse, buy, subcontract,
etc.
● Constraints imposed on the application : costs, schedule,
interface, environmental limitation, etc.
Second Quadrant: Risk Analysis ( Evaluate
alternatives, Risk Assessment and mitigation)
– Alternative solutions are evaluated and examine the
risks associated with these objectives.
– Risk: any adverse circumstance that might hamper
the successful completion of a software project.

– Steps are taken to reduce the risk.

– For example, if there is a risk that the requirements are
inappropriate:
• a prototype system may be developed
 Spiral Model cont…
● Third quadrant: Engineering (Development and
Validation)
– Develop and validate based on the decision taken into the
first two phases.
– Typical activities are design, review of design, coding,
inspection of code, and testing.

● Fourth quadrant: Evaluation (Review and Planning )

– Review the results achieved so far with the customer and
plan the next iteration around the spiral.
– whether to proceed to the next phase or make changes to the
project plan.

● With each iteration around the spiral progressively more

complete version of the software gets built.
 Spiral Model cont…
● The team must decide:
– how to structure the project into phases.
● The major distinguishing feature of the Spiral
model is that it creates a risk-driven approach
to the software process rather than a
primarily document-driven or code-driven
process.
● Efforts and detail driven by risks.
● Adaptive model
 Advantages
• Adaptive
• Risk focus increases chance of success.
• Flexible for using any model.
• Minimum waste.
• Options for go/no-go
 Disadvantages
• Complexity
• Resource Intensive hence not suitable for small projects.
• Model requires expertise in risk management and
excellent management skills.
• Documentation overhead: The large number of
intermediate stages can create additional internal and
external documentation to process.
• Expensive
• Need stakeholder engagement.
 Spiral Model Application
• For medium to high-risk projects.
• When there is a budget constraint and risk evaluation is
important
• New product line which should be released in phases to get
enough customer feedback
• Long-term project commitment because of potential changes
to economic priorities as the requirements change with time.
• Requirements are complex and need evaluation to get clarity
• Significant changes are expected in the product during the
development cycle
• When the technology is new and test of basic components
are required.
 Spiral Model as a meta model
● Subsumes all discussed models:
– a single loop spiral represents waterfall model.
– uses an evolutionary approach --
● iterations through the spiral are evolutionary levels.
– enables understanding and reacting to risks
during each iteration along the spiral.
– uses:
● prototyping as a risk reduction mechanism
● retains the step-wise approach of the waterfall model.
 Comparison of Different Life Cycle
Models
● Waterfall model
– most widely used model.
– But, suitable only for well-understood problems.

● Prototype model is suitable for projects not

well understood:
– user requirements
– technical aspects
 Comparison of Different Life Cycle
Models cont…
● Evolutionary model is suitable for large
problems:
– can be decomposed into a set of modules that
can be incrementally implemented,
– incremental delivery of the system is acceptable
to the customer.
● The spiral model:
– suitable for development of technically
challenging software products that are subject
to several kinds of risks.
 Example
Scenario:
A software development team is tasked with creating a
prototype for a new data analytics platform. The client has
provided minimal requirements and expects the prototype to
demonstrate key functionalities and user interface concepts.

Question:
How can the Spiral Model help the development team to
create an effective prototype for the data analytics platform?
 Sample Answer
The Spiral Model's iterative nature is well-suited for developing
prototypes, particularly when requirements are not well-defined.
In the initial spiral iteration, the team can focus on gathering
requirements from the client and defining the scope of the
prototype. Subsequent iterations can then be used to develop
and refine key functionalities and user interface elements based
on stakeholder feedback.
By incorporating user input early and often, the team can ensure
that the prototype meets the client's expectations and
demonstrates the desired features and functionality of the data
analytics platform. Additionally, the Spiral Model allows for
flexibility in adjusting the prototype based on changing
requirements or priorities as the project progresses.
 Quiz
• Which model emphasizes delivering a functional
version of the software early, with additional
features added in later versions?
a. Waterfall Model
b. Prototype Model
c. Incremental Model
d. Spiral Model
 The RAD Model
• The Rapid Application Development methodology was
developed to respond to the need to deliver systems
very fast.
– incremental software development process model
that allows usable systems to be built in as little as
60-90 days.
• Important feature of RAD model is increased
involvement of the user/customer at all stages
• Emphasizes on an extremely short development cycle
• Takes advantage of automated tools and techniques to
restructure the process of building information
systems.
 The RAD Model
• In RAD a prototype is a working model
that is functionally equivalent to a
component of the product.
– Components or functions are developed in
parallel as if they were mini projects.
• In RAD model the functional modules are
developed in parallel as prototypes and
are integrated to make the complete
product for faster product delivery.
 The RAD Model
Team # n
M o d e lin g
business m odeling
dat a m odeling
process m odeling

Co n s t r u c t io n
com ponent reuse
Team # 2 aut om at ic code
Com municat ion generat ion
t est ing
Mo d eling
b u si n e ss m o d e l i n g
dat a m odeling
p ro ce ss m o d e l i n g

Planning
Co nst r uct io n De ployme nt
Team # 1 co m p o n e n t re u se int egrat ion
a u t o m a t i c co d e
g e n e ra t i o n deliv ery
Mode ling t e st i n g feedback
business modeling
dat a modeling
process modeling

Const r uct ion

component reuse
aut omat ic code
generat ion
t est ing

6 0 - 9 0 days
 RAD Characteristics
• Iterative development
• Prototyping
• User involvement
• Time-boxed development
• Incremental delivery
• Flexible and adaptive
 RAD Model Application
• When a system can be modularized to be delivered in
incremental manner.
• It should be used if there is high availability of designers
for modeling.
• It should be used only if the budget permits use of
automated code generating tools.
• RAD SDLC model should be chosen only if domain
experts are available with relevant business knowledge.
• Should be used where the requirements change during
the course of the project and working prototypes are to
be presented to customer in small iterations of 2-3
months.
RAD Model Application Cont..
• On system that do not require high
performance.
• When reusable parts are available.
• On system with reasonably well known
requirements.
 Disadvantages
• Highly specialized and skilled developers are required.
• Model is ineffective if system can not be properly
modularized.
• Absence of reusable components can lead to a failure of
the project.
• Dependency on user involvement
• An efficient, accelerated development process must be
in place for quick response and feedback.
• Risk of scope creep
 Case Study
• A real-world example of the RAD model in action is
the development of the TurboTax software by Intuit.
– TurboTax is a tax preparation software used by millions of
individuals and businesses to file their taxes each year.
– Intuit employs a RAD approach to continuously improve
TurboTax based on user feedback and changing tax laws.
The company releases new versions of the software
annually, with updates and enhancements based on
customer input and iterative development cycles.
– Intuit's use of the RAD model allows it to quickly adapt to
changing user needs and regulatory requirements while
maintaining a user-friendly interface and reliable
performance.
 Other Process Models
• Component based development—the process to apply
when reuse is a development objective
• Formal methods—emphasizes the mathematical
specification of requirements
• Aspect-Oriented Software Development—provides a
process and methodological approach for defining,
specifying, designing, and constructing aspects
• Unified Process—a “use-case driven, architecture-
centric, iterative and incremental” software process
closely aligned with the Unified Modeling Language
(UML)
• Agile Model
 Quiz
• What is the primary goal of the Evaluation
phase in the Spiral Model?
a. To develop the final product
b. To identify and mitigate risks
c. To gather user feedback
d. To create detailed design documents
 Discussion Questions
• What problem would a software development
organization face if it does not have a
documented process model, and therefore ,
follows only an informally described life cycle
model?
• What do you mean by the “99% complete”
syndrome in software development? Why does it
occur? What is its implication for project
management and what are its remedies?
Questions?
Rapid Action Development Model
To RAD or not to RAD

The Rapid Application Development methodology was developed to respond to the need to deliver systems very fast.
The RAD approach is not appropriate to all projects - an air traffic control system based on RAD would not instill
much confidence. Project scope, size and circumstances all determine the success of a RAD approach. The following
categorize indicates suitability for a RAD approach:

PROJECT SCOPE
Suitable for RAD - Focused scope where the business objectives are well defined and narrow.
Unsuitable for RAD - Broad scope where the business objectives are obscure or broad.

PROJECT DATA
Suitable for RAD - Data for the project already exists (completely or in part). The project largely comprises analysis or
reporting of the data.
Unsuitable for RAD - Complex and voluminous data must be analyzed, designed and created within the scope of the
project.

PROJECT DECISIONS
Suitable for RAD - Decisions can be made by a small number of people who are available and preferably co-located.
Unsuitable for RAD - Many people must be involved in the decisions on the project, the decision makers are not
available on a timely basis or they are geographically dispersed.

PROJECT TEAM
Suitable for RAD - The project team is small (preferably six people or less).
Unsuitable for RAD - The project team is large or there are multiple teams whose work needs to be coordinated.

PROJECT TECHNICAL ARCHITECTURE

Suitable for RAD - The technical architecture is defined and clear and the key technology components are in place
and tested.
Unsuitable for RAD - The technical architecture is unclear and much of the technology will be used for the first time
within the project.

PROJECT TECHNICAL REQUIREMENTS

Suitable for RAD - Technical requirements (response times, throughput, database sizes, etc.) are reasonable and
well within the capabilities of the technology being used. In fact targeted performance should be less than 70% of the
published limits of the technologies.
Unsuitable for RAD - Technical requirements are tight for the equipment to be used.

Rapid means Fast

The RAD method has a task list and a work breakdown structure that is designed for speed. However the major
difference in RAD is a set of management techniques that are optimized for speed. Among the most important are:

- Prototyping - an approach based on creating a demonstrable result as early as possible and refining that result. The
refinement is based on feedback from the business, the eventual users of the system. Prototyping requires an open
approach to development, it also requires an emphasis on relationship management and change management. There
are dangers involved in starting prototype development too early and in starting it too late.

- Iteration - is a commitment to incremental development based on refinement. Prototyping and iteration go hand in
hand.

- Timeboxing - is a management technique that focuses attention on delivery above all else. Under a timebox scope
can change but delivery cannot.
Case Study:

A software development company has been contracted to build a new accounting software for a
large financial institution. The requirements are well-defined, and the client expects a detailed
plan before development begins.
Questions:
1. How would you apply the Waterfall model to this project?
2. What are the potential advantages and disadvantages of using the Waterfall model in
this scenario?
3. Discuss the implications of using the Waterfall model if there are changes in
requirements during the development process.
4. Can you suggest any modifications to the Waterfall model that might make it more
flexible for evolving requirements?

Sample Answer
1. Waterfall model is a liner sequential model consisting of following phases:
(i) Requirement Analysis: The software development company would start by
thoroughly analyzing the requirements provided by the financial institution. This
includes understanding their accounting processes, compliance needs, reporting
requirements, and user expectations.
(ii) Design: Once the requirements are well-understood, the company will proceed
with designing the architecture, database structure, user interface, and other
technical aspects of the accounting software.
(iii) Implementation: After the design, the development team would begin coding the
software based on the specifications outlined in the design phase.
(iv) Testing: After implementation, the software undergoes comprehensive testing to
ensure that it meets the specified requirements and functions as intended. The
testing process includes unit testing, integration testing, system testing, and user
acceptance testing.
(v) Deployment: After testing and approval by the client, it is deployed into the actual
environment for use by the financial institution.
(vi) Maintenance: The final phase involves providing ongoing maintenance and
support to address any issues, implement updates, and incorporate new features
as needed.
2. Advantages and Disadvantages of Using the Waterfall Model:
Advantages:
(i) Clear Documentation: The Waterfall model emphasizes detailed documentation at
each stage, helping to ensure that requirements are well-understood and project
progress is easily tracked.
 (ii) Predictability: With a well-defined plan upfront, the project timeline, budget, and
deliverables are relatively predictable.
(iii) Structured Approach: The linear nature of the Waterfall model provides a
structured framework for development, making it easier to manage and track
progress.
Disadvantages:

(i) Rigid Phases: Progression from one phase to the next is strictly sequential,
which can lead to delays if any phase takes longer than anticipated.
(ii) Limited Flexibility: The Waterfall model is inflexible and does not easily
accommodate changes once the development process has begun.
(iii) Late Feedback: Since testing occurs towards the end of the project, any
issues or defects may not be identified until after significant resources have
been invested.

3. If changes in requirements occur during the development process in a Waterfall model, it

can have significant implications:
Scope Creep: Changes in requirements may lead to scope creep, where the project
expands beyond its original boundaries, resulting in increased costs and timeline
extensions.
Risk of Rework: Adapting to new requirements may require extensive rework of earlier
stages, leading to delays and added expenses.
Client Dissatisfaction: If changes in requirements are not handled effectively, it can lead
to dissatisfaction and strained client relationships, as the final product may not meet their
evolving needs and expectations of the client.

Case Study:

A startup is developing a new mobile application for language learning. The founders
have a basic idea of the features they want but are open to exploration and feedback
from potential users.
Questions:
1. Explain how the Prototype model could be utilized in the development of the language
learning mobile application.
2. What are the main benefits of using a Prototype model in a project like this?
3. Discuss the challenges that might arise when using prototypes, especially in terms of
managing client expectations.
4. Can you describe a scenario where the Prototype model might not be the best fit for a
project?

Ans:
1. Utilizing the Prototype Model in Language Learning App Development:
In the development of the language learning mobile application, the Prototype model can
be employed in several ways:

Initial Conceptualization: The team can start with a basic prototype that outlines the core
features and functionalities of the application. This prototype can serve as a visual
representation of the app's layout, user interface, and navigation flow.

Iterative Development: The Prototype model allows for iterative development, where the
team can gradually refine and enhance the application based on user feedback. They can
create multiple prototypes with incremental improvements to test different ideas and
gather user input.

User Testing and Feedback: Prototypes can be used to conduct user testing sessions where
potential users interact with the application and provide feedback. This feedback can be
invaluable in identifying usability issues, understanding user preferences, and refining the
overall user experience.

2. Benefits of Using a Prototype Model:

Early Validation: Prototypes allow for early validation of ideas and concepts before
investing significant time and resources into full-scale development.

User-Centered Design: By involving users in the prototyping process, the team can ensure
that the final product meets the needs and expectations of the target audience.

Cost-Effectiveness: Prototyping helps identify design flaws and usability issues early on,
reducing the cost of making changes later in the development process.

Iterative Improvement: The iterative nature of prototyping enables continuous

improvement based on user feedback, leading to a more refined and polished final
product.

3. Challenges of Using Prototypes:

 Managing Expectations: One of the challenges is managing client expectations, as clients
may sometimes confuse prototypes with final products and expect full functionality and
polish from early prototypes.

Scope Creep: Continuous iteration based on user feedback can lead to scope creep if not
managed properly. It's important to establish clear criteria for incorporating feedback and
prioritize features accordingly.

Resource Allocation: Developing prototypes requires time and resources, and there's a
risk of investing too much in prototyping without achieving tangible results.

4. Scenario Where Prototype Model Might Not Be the Best Fit:

Highly Technical Projects: In projects where the feasibility of technical aspects is the
primary concern, such as developing complex algorithms or intricate backend systems,
the Prototype model might not be the best fit. In such cases, a more research-oriented or
proof-of-concept approach might be necessary before moving on to prototyping the user
interface and experience. Additionally, projects with rigid and well-defined requirements
may not benefit as much from the iterative nature of the Prototype model, as there may
be less room for exploration and iteration.
Agile Software Development
Process
 Objective

Agile development methods emerged in the late

1990s whose aim was to radically reduce the
delivery time for working software systems
Plan-driven and Agile development
 What Is Agile
Software Development?
• “Agile Development” is an umbrella term for
several iterative and incremental software
development methodologies.
– most popular agile methodologies include Extreme
Programming (XP), Scrum, Crystal, Dynamic Systems
Development Method (DSDM), Lean Development,
and Feature-Driven Development (FDD).
 Agile Methodology of Software
Development
• Agile approach emphasizes iterative
development, collaboration between cross-
functional teams, customer feedback, and
adaptability to change.
• It aims to deliver high-quality software
products incrementally, focusing on delivering
small, manageable pieces of functionality in
short timeframes called sprints.
 What Is Agile
Software Development?
• Agility is the ability to deliver customer value
while dealing with inherent project
unpredictability and dynamism by recognizing
and adapting to change.
• Agile is characterized by the division of tasks
into short phases of work and frequent
reassessment and adaptation of plans.
• Each of the agile methodologies is unique in its
specific approach but they all share a common
vision and core values:
– Iteration and the continuous feedback that provides
successively refine and deliver a software system.
– All methodology involve continuous planning,
continuous testing, continuous integration, and other
forms of continuous evolution of both the project and
the software.
– Lightweight compared to traditional waterfall-style
processes, and inherently adaptable.
– In agile methods focus on empowering people to
collaborate and make decisions together quickly and
effectively.
• Agile development offers a lightweight
framework for helping teams, given a
constantly evolving functional and technical
landscape, maintain a focus on the rapid
delivery of business value

• What is more important about agile methods

is that they all focus on empowering people to
collaborate and make decisions together
quickly and effectively.
The Agile Manifesto–a statement of
values

Individuals and
over Process and tools
interactions
Comprehensive
Working software over
documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

Source: www.agilemanifesto.org
Agile vs. Traditional S/W Development
Scrum Methodology
 What is Scrum?

A Better Way Of Building Software

An iterative and incremental agile software development framework for

managing product development.
 We’re losing the relay race
“The… ‘relay race’ approach to product
development…may conflict with the goals of
maximum speed and flexibility. Instead a holistic or
‘rugby’ approach—where a team tries to go the
distance as a unit, passing the ball back and forth—
may better serve today’s competitive requirements.”

Hirotaka Takeuchi and Ikujiro Nonaka, “The New New

Product Development Game”, Harvard Business Review,
January 1986.
 Scrum…
• Scrum is an agile method that provides a project
management framework.
• It allows us to focus on delivering the highest business
value in the shortest time.
• It allows us to rapidly and repeatedly inspect actual
working software (every two weeks to one month).
• The business sets the priorities. Teams self-organize to
determine the best way to deliver the highest priority
features.
• Every two weeks to a month anyone can see real
working software and decide to release it as is or
continue to enhance it for another sprint.
 Major role in Scrum Development
• Product Owner:
– Main job is to product vision into live.
– Understanding business and market requirements
– Prioritize the work

• Scrum Master
– Scrum expert in the team and responsible for gluing everything together and
ensuring that scrum is being done well.
– Help the product owner define value, the development team deliver the value, and
the scrum team to get to get better.
– The scrum master is a servant leader
– Scrum master helps the team to self-organize, focus on outcomes, get to a “done
increment,” and manage blockers

• Development Team
– Team of designers, programmers, writers etc.
– Work daily on product development i.e. Sprint
– How to improve development practices
– Self organize
 The Scrum Framework
• A product owner creates a prioritized wish list called a product
backlog.
• During sprint planning, the team pulls a small chunk from the top of
that wish list, a sprint backlog, and decides how to implement those
pieces.
• The team has a certain amount of time — a sprint (usually two to
four weeks) — to complete its work, but it meets each day to assess
its progress (daily Scrum).
• Along the way, the Scrum Master keeps the team focused on its
goal.
• At the end of the sprint, the work should be potentially shippable:
ready to hand to a customer, put on a store shelf, or show to a
stakeholder.
• The sprint ends with a sprint review and retrospective.
• As the next sprint begins, the team chooses another chunk of the
product backlog and begins working again.
 Scrum Team
• Typically 4-8 people
• Cross-functional:
• Programmers, testers, user experience designers,
etc.
• Members should be full-time
• May be exceptions (e.g., Network administrator)
• Self organized
• Ideally, no titles but rarely a possibility
 Keywords
• Product owner
– Define the features of the product
– Decide on release date and content
– responsible for the profitability of the product (ROI)
• Adjust features and priority every iteration, as
needed
• Accept or reject work results
• The Scrum Master
• Represents management to the project
• Removes impediments
• Ensure that the team is fully functional and productive
• Enable close cooperation across all roles and functions
• Shield the team from external interferences
• Sprints
– Scrum projects make progress in a series of “sprints”
– Typical duration is 2–4 weeks or a calendar month at
most
– Product is designed, coded, and tested during the
sprint
 Quiz
Q. Which of the following questions is not
relevant for regular Scrum Meeting?
a. What have you done since the last Daily Scrum
regarding this project?
b. What will you do between now and the next
Daily Scrum meeting regarding this project?
c. Would you be able to finish your work on time?
d. What impedes you from performing your work
as effectively as possible?
Scrum – Roles, Artifacts, Ceremonies
 Quiz
• When is a Sprint Retrospective
ceremony performed?
a. At the end of each Sprint
b. Whenever needed
c. Whenever the Product Owner
suggests
d. Whenever the Scrum Master
suggests
 Kanban
(A framework used to implement agile software development)
Questions?
What is a Requirement?

One of the most critical aspects of Software Product Management deal with conditions
known as requirements. Many definitions have been developed to describe “requirements.”
A requirement is most easily understood as a specific description of your client’s needs,
which can be used to help create a real-world product.

The Institute of Electrical and Electronics Engineers (IEEE) defines a requirement as:

1. A condition or capability needed by a user to solve a problem or achieve an

objective.

2. A condition or capability that must be met or possessed by a system or system

component to satisfy a contract, standard, specification, or other formally imposed
documents.

3. A documented representation of a condition or capability as in (1) or (2). (IEEE,

1990). Well-defined requirements help make sure client needs are understood and
addressed and also help detect potential problems before they become large and
expensive to fix.

Requirement Engineering Activities

will explore five important requirements activities:

1. Eliciting requirements

2. Expressing requirements

3. Prioritizing requirements

4. Analyzing requirements

5. Managing requirements

With these activities, the right requirements can be established, written in proper form,
and even improved.

Eliciting Requirements

The activity of eliciting requirements is an interactive and investigative process, which

occurs when meeting with the client and users.

Clients often have ideas about what features they would like in a product and what these
features should look like. Many clients, however, have limited knowledge of how software is
built and vague ideas regarding what makes a project successful. It can be difficult then for

1
clients to understand what they truly require in a product. It is the role of the software
product manager to help the client figure out what they “want” and what they “need.”

A “want” is usually a functionality or feature that the client would like the product to have,
which may add value, but is not necessarily core to the product itself. A “need,” on the other
hand, is a core functionality that the product must have in order to fulfill the product’s
purpose. Needs should take priority in product development.

The best way to discover and develop “needs” and “wants” with your client is through
eliciting requirements, where you engage in discussion about the product with your client.
Through discussion, the software product manager and team can help provide insights on
what the client “needs” and “wants” the product to do, and how these goals can be feasibly
achieved. It may be that the initial vision the client had of the product will have changed, but
through involvement with the software product team, any changes should feel proactive and
the client should feel reassured that the team understands users’ needs.

Note that eliciting requirements as “needs” and “wants” does not necessarily mean that all
the client’s features and ideas that fall in the “want” category are not doable or should be
dismissed. In fact, these ideas may be very good. But it is the role of the software product
manager to make sure that the goals are feasible, client expectations are realistic, and the
product produced is the best possible result. Eliciting requirements should not be confused
with “requirements gathering.” “Requirements gathering” is the more passive approach of
simply asking the client what they would like done, and it often puts the development team
in a reactive process. Eliciting requirements, however, engages in in-depth discussion and
collaboration from the start of product development, so both the client and the development
team work together to build a successful product.

Expressing Requirements

Once client needs have been established by eliciting requirements, the activity of expressing
requirements comes into play. Expressing requirements involves framing the requirements
identified through discussion in a way that allows a product to be built.

Often, requirements are first described through notes from meetings with clients. From
there, better and more concrete representations can be used for expressing requirements.
Typical representations include use cases, user stories, or storyboards, among others.
These are often tailored to the project. They could be simple or complex, textual or visual. It
is up to the software product manager and team to determine and use representations that
would work best for the project at hand.

Prioritizing Requirements

2
Once a vision of what needs to be done for the project has been established through both
eliciting and expressing requirements, it is important to prioritize client needs, especially in
Scrum methodology.

Questions to help establish priorities include:

• What requirements must be completed for the project and product to be successful?

• What requirements should be done? In other words, what is important but is not as time-
critical or could be satisfied another way or at a later time on the project?

• What could be done to improve the project or product but is not necessary? These
priorities are usually only included if both time and resources allow for it.

The questions outlined here closely follow the MoSCoW method of prioritization, developed
by Dai Clegg. This method is used to help reach an understanding with clients on the
importance of each requirement. “MoSCoW” is an acronym for the categories of “Must
have”, “Should have”, “Could have” and “Would like but won’t get.” By asking the questions
suggested here, requirements can be placed in these.

Analyzing Requirements

The process of examining the listed requirements of a project to ensure that they are clear,
complete, and consistent is known as analyzing requirements. Analyzing requirements
helps ensure that the product is the best one possible. It is an important process, and a
constant one. A project must be continually evaluated and requirements improved as it
progresses. This adaptive nature is important in Agile systems.

Analyzing requirements helps to resolve any potential conflicting requirements or to identify

problems between requirements that might not be easily seen at first glance. It also ensures
that the requirements identified truly reflect and relate to the product being built.

Managing Requirements

The activity of managing requirements is also a continuous process. It involves the

organizing and re-organizing of requirements and possibly reusing subsets of requirements
in different stages. It also involves keeping track of priorities, analyses, and changes in
requirements. This is very important because everything is connected in a project. If
something changes in one requirement, it will affect other requirements and the
development of the product. Managing requirements also means ensuring that the identified

3
requirements are central to the many processes of product creation, including coding,
testing, and change logs.

Types of Requirements

Now that we’ve covered what requirements are and the activities involved with getting them
right, let’s dive into a little more detail and introduce some different types of requirements.
This notes will cover the following types of requirements:

• Business requirements

• Business rules

• User requirements

• Functional requirements

• Non-functional requirements

• External interfaces

• Physical product settings

• Development constraints

While business requirements and business rules can influence the project, it’s user
requirements, functional requirements, and non-functional requirements that are
considered the most essential requirements. Finally, external interfaces, physical product
settings, and development constraints are requirements that add context for design and
implementation of the product.

Business Requirements

There are many possible definitions for business requirements. In this course, business
requirements refer to those requirements that involve the purpose of the project. In business
requirements, goals are presented in concrete and specific terms. These goals are usually
tangible or quantifiable business values that can be used by business analysts.

An example of a business requirement might be: “The client needs to reduce errors in orders
made to their company by 25% by the end of next year to raise their yearly revenue by
$10,000.

Business Rules

Business requirements should not be confused with business rules, although they are often
associated. Business requirements deal with why the project was pursued, while business

4
rules are constraints on how the product will function. Business rules are sometimes
necessary to make a project appropriate or successful. They are often budgets, policies,
guidelines, or regulations. Examples of business rules include:

• Government or legal regulations

• Privacy policies

• Brand uniformity requirement

User Requirements Users or end-users are the people who will use the software once it has
been created. User requirements are the tasks that these users can accomplish with the
product, or what the product can do for the user. User requirements are very important
requirements to the project, if not the most important. They are part of the core functionality
of the product. For this reason, determining user requirements is usually very time
consuming.

There are many methods for expressing user requirements, including:

• Use cases

• User stories

• Storyboards

• Scenarios

Scenarios refer to cases where the client or end-user describes user requirements in their
own words. These descriptions can sometimes be vague or non-specific. It is part of the role
of the software product manager to help organize and refine their needs in more concrete
manners, so the development team knows how to best build the product.

Use cases, user stories, and storyboards are explored in more depth below.

Functional Requirements

Functional requirements are those behaviours that the developed product should do or
support. These are usually expressed as inputs into the product, outputs of the product, or
a description of the behaviour itself. For example, input might be data related to a user’s
online purchase, including name, address, item purchased, and payment information. The
output in this scenario might be a notification email after the transaction is performed.

Often, functional requirements need to be expressed with depth and specificity. Information
flow diagrams are a graphical technique commonly used to show how data flows

5
throughoutthe system and the dependencies of all the system components. Together, an
information flow diagram shows how the entire system functions.

The following is an example of an information flow diagram for a customer using a credit card
with a product, and where the credit card information is verified before a receipt is generated
for the user.

Non-functional Requirements

In addition to functional requirements, there are non-functional requirements that describe

how well a product must perform. They are also known as quality requirements for this

6
reason. Non-functional requirements address product issues including accuracy,
dependability, security, usability, efficiency, performance, and maintainability.

Drawing on the online purchasing example used in functional requirements, a non-

functional requirement in the same scenario would be that emails should be delivered to
users within two hours of purchase. Non-functional requirements are usually
complementary to functional requirements.

External Interfaces

External interfaces requirements refer to those requirements related to how the product is
situated within a larger system. In other words, external interfaces do not concern
themselves with the physical environment of the product, but rather they are concerned with
the relationship of the product to other entities outside the product.

For example, a software application that retrieved information from a remote database to
display to users sits between the entities of the database and the end-user. An external
interface is used between each one. Interfaces also involve the way connections are made
through media, protocols, formats, and levels of compatibility.

External interfaces can be represented within data flow diagrams that show all the
components of a product, including outside entities. These data flow diagrams make explicit
reference to the flow of data from other entities and the product within an entire system.

Physical Setting

Physical setting requirements refer to how the product needs to be designed in order to
function in its physical environment. For example, if a product was being developed for
underwater exploration, it would need to be waterproof. Similarly, if the product was
designed for use in the desert, or in Antarctica, it would need to withstand and function in
those environments.

Development Constraints

Development constraints affect everything from implementation technology, conventions,

documentation, and the process used to develop the product. They generally refer to
constraints related to creating the product, such as which devices or platforms will be
supported, or how much memory, bandwidth, or processing power the product is limited to
using. It is beneficial to address development constraints as late as possible in the
specification phase because technology changes rapidly

7
Requirement Engineering
(Requirement Analysis & Specification)
 Objective

Objective is to discuss requirement engineering

task and basic requirements analysis concepts
and principles.
 Learning Outcome
• After Completing the module student will
be able to gather, analysis and document
the customer requirements for small to
medium size application development.
 Introduction
• Many projects fail It is important to
because they start learn:
implementing the Requirements
system.. analysis and
– Without specification
determining
techniques
whether they are
building what the carefully.
customer really
wants.
 Introduction (What is It ?)
• Requirement is a feature of the system or a
description of something the system is capable
of doing in order to fulfill the system’s purpose
• Requirement engineering helps software
engineers to better understand the problem they
will work to solved
• Lead to an understanding of what the business
impact of the software will be, what the customer
wants, and how end-users will interact with the
software
 Introduction (What is It ?)
• Requirement engineering is defined as the
systematic process of documenting
requirements through an interactive and
co-operative process of analyzing the
problem, documenting the resulting
observations in a variety of representation
format, and checking the accuracy of the
understanding gain.
 Requirement Engineering is the
process of defining, documenting and
maintaining the requirements.
 Introduction (Who Does It?)
• Usually carried out by an experienced
member of the development team.
• Engineers who gather and analyze
requirements and then document them are
known as system analysts.
• The system analyst’s job is to understand the
precise requirements of the user and other
stakeholders and analyze the requirements to
weed out inconsistencies, anomalies, and
incompleteness and put them in a document
i.e. SRS.
 Requirement Engineering
Activities
• Broadly requirement engineering
(requirement process) consists of the
following distinct activities:
– Requirement Gathering & Analysis
or Requirement Elicitation
– Requirements Specification (documentation)
– Requirement Validation
– Requirement Management
 Requirements Gathering &
Analysis
Requirements Gathering & Analysis
• This activity is also known as requirement
elicitation.
• Purpose is to obtain a clear understanding of the
needs of the clients and the users, goals, the
constraints from the stakeholders.
• A stakeholder is a person or group of persons
who are either directly or indirectly related to the
system like the user, customer, software
developer etc.
 Requirements Gathering &
Analysis
Requirements gathering/Elicitation
• Purpose is to obtain a clear understanding of the needs
of the clients and the users, goals, the constraints from
the stakeholders for the system.
• Several techniques can be used to elicit requirements,
including
– Observation of existing systems
– Interviews
– Surveys
– Prototyping
– Discussion with the customer and end-users,
 Requirements Gathering

• Some desirable attributes of a

good system analyst:
–Good interaction skills,
–Imagination and creativity,
–Experience.
Requirement Gathering Methods
• Studying existing documents (Document Analysis)
• Interview
• Questioners
• Focus group
• Task analysis
• Scenario analysis
• Form Analysis
• Prototyping
 Useful tools for Requirements
Gathering
• Mind mapping
– Logical way of note-taking and note-making
• Use Case
– As-Is and To-Be model
• Context diagram
– Define system boundary, surrounding environment
and all interacting entity
• Functional decomposition diagram
– Break down the system into major components
 Prioritizing Requirements
• It is important to prioritize client needs,
especially in Scrum methodology.
• Questions to help establish priorities include:
– What requirements must be completed for the project
and product to be successful?
– What requirements should be done?
• In other words, what is important but is not as time-critical or
could be satisfied another way or at a later time on the
project?
– What could be done to improve the project or product
but is not necessary? These priorities are usually only
included if both time and resources allow for it
• Follow MoSCoW method
 MoSCoW method
• Method of prioritization, developed by Dai Clegg.
– used to help reach an understanding with clients on the
importance of each requirement
• “MoSCoW” is an acronym for the categories of
– “Must have”,
– “Should have”,
– “Could have”
– “Would like but won’t get.”
• By asking the questions suggested here, requirements
can be placed in these
 Requirements Gathering &
Analysis
• Requirements Analysis
• For carrying out requirement analysis effectively,
the analyst needs to clearly understand the system
and the problem.
• What is the problem?
• Why is it important to solve the problem?
• What are constraints?
• What are the possible solutions to the problem?
• What exactly are the data input to the system and what
exactly are the data output required?
• What are the likely complexities that might arise while
solving the problem?
• Data exchange format
 Requirements Gathering &
Analysis
• Requirement Analysis (cont..)
• Analyst’s job is to identify and resolve the various
requirements and problems
• Anomaly
– ambiguity in the requirement
– Several interpretations of the requirement are possible
• Inconsistency
– Any one of the requirements contradicts another
• Incompleteness
– Some of the requirements overlooked
– Caused by the inability of the customer to visualize and
anticipate all the features
 Requirements Gathering &
Analysis
• Requirement Analysis (cont..)
– The requirements must maintain a standard quality,
different types of requirement quality include
•
 Example
• Anomaly
– In a process control application, a stakeholder
expresses his requirement
“ When the temperature becomes high, the
heater should be switched off.”
Words like “high”, “low”, “Good” etc. introduces
anomaly in the requirements.
 Inconsistent Requirement
• Some part of the requirement:
– contradicts with some other part.
• Example:
– One customer says turn off heater and open
water shower when temperature > 100 C
– Another customer says turn off heater and
turn ON cooler when temperature > 100 C
 Requirement Quality
Example of bad Example of good
Requirement Quality
requirement requirement

•Students will be able to

•Students will be able to enroll to undergraduate
enroll to undergraduate courses
Atomic
and post graduate •Students will be able to
courses enroll to post-graduate
courses

A professor user will log A professor user will log

into the system by into the system by
Complete providing his username, providing his username,
password, and other password and
relevant information department code
 Requirement Quality
Example of bad Example of good
Requirement Quality
requirement requirement
A student will have
either undergraduate
courses or post- A student will have
Consistent and graduate courses but either under-graduate
unambiguous not both. Some courses or postgraduates but
will be open to both not both
under-graduate and
post-graduate
Maintain student Maintain student
Traceable information-mapped to information-Mapped to
BRD req.ID? BRD req ID 4.1
Register student and
Each page of the
enrol courses pages of
Testable system will load in an
the system will load
acceptable time-frame
within 5 seconds
 Requirements Gathering &
Analysis
• List of activities helpful while collecting and
analyzing requirements:
– Identifying the stakeholders
• Create a list of people who will contribute in input
– Recognizing multiple viewpoints
– Working towards collaboration
• Identify areas of commonality and area of conflict.
 Requirements Specification
• Main aim of requirements specification:
– Systematically organize the requirements
arrived during requirements analysis.
• Issues such as representation, specification
languages, and tools are addressed during this
activity
• Specify only what the software is supposed to do
i.e. focus on the external behavior of the system
 Requirements Specification
• Two kinds of requirements documents
– Requirements definition document
• Written in terms that the customer can understand
• Complete listing of everything the customer
expects the proposed system to do
• Represents an understanding between the
customer and developer of what customer needs
• Written jointly by the customer and developer
 Requirements Specifications
Cont..
– Software requirement s specification (SRS)
• Restate the requirements definition in technical
terms appropriate for the development of a system
design.
• Also defines constraints and assumptions.
• Sometime a single document serve both
purposes
 Requirements Specifications
Cont..
• The SRS document is known as black-box
specification:
– the system is considered as a black box
whose internal details are not known.
– only its visible external (i.e. input/output)
behaviour is documented.
Input Data Output Data
S
 Requirements Specifications
Cont..
● SRS document concentrates on:
– What needs to be done
– Carefully avoids the solution (“how to do”)
aspects.
 Requirements Documents Cont..
Software Requirements Specification (SRS) cont..
• Need for SRS
– Bridge the communication gap between parties involved in the
development project
– Helps the clients to understand to understand their own needs
– Establishes the basis for agreement between the client and the
supplier on what the software product will do
– Provides a reference for validation of the final product.
– A legal document
– A high quality SRS is a prerequisite to high-quality software
– Support project management and control
– Controlling the evolution of the system
– High-quality SRS reduce the development cost
 Characteristics of a Good SRS
Document
• Some of the desirable qualities of the SRS
documents are
– Correct
– Concise
– Complete
– Structured
– Black-Box View
– Response to undesired events
– Verifiable
 Unambiguous Requirements

•REQ1 On the “Stored Flight” screen, the user can only view one
record.
Does this mean that the user can “only view,” not delete or update,
or does it mean that the user can view only one record, not two or
three?

One way to fix the problem is to rewrite the requirement from the
system’s point of view:

•REQ1 On the “Stored Flight” screen, the system shall display only
one flight.
 Verifiable Non-Functional Requirements

Example: The system shall be easy to use

Better expressed as:

Experienced user shall be able to use the all the system

functions after a total of five hours training. After this
training, the average number of errors made by
experiences user shall not exceed two per day.
What is not included in an SRS ?
• Project requirements
• Cost, delivery schedules, staffing, reporting
procedures
• Design solutions
• Partitioning of SW into modules, choosing data
structures
• Product assurance plans
• Quality Assurance procedures, Configuration
Management procedures, Verification & Validation
procedures
 Examples of Bad SRS
Documents
• Unstructured Specifications:
– Narrative essay --- one of the worst types of
specification document:
• Difficult to change,
• difficult to be precise,
• difficult to be unambiguous,
• scope for contradictions, etc.
 Examples of Bad SRS
Documents
• Noise:
– Presence of text containing information
irrelevant to the problem.
• Silence:
– aspects important to proper solution of the
problem are omitted.
 Examples of Bad SRS
Documents
• Over-specification
– Try to address the ‘how to’ aspects.
– Restricts the freedom of the designer in arriving at a
good design solutions.
• Forwarded references
– Refer to the aspects that are discussed much later in
the SRS document.
• Wishful thinking
– Description of aspects which would be difficult to
implement.
Structure of an SRS
 SRS Document
(Categories of Customer Requirements)
• SRS document, normally categorizes
and organizes the requirements into the
following categories:
– Functional requirements,
– Non-functional requirements,
 Types of Requirements
• Functional requirements
• Nonfunctional requirements
– Performance requirements
– Interface requirements
– Design constraints
– Other requirements
 Functional Requirements
● Functional requirements are product features or
functions that developers must implement to enable
users to accomplish their tasks.
● Functional requirements describe:
– A set of high-level requirements
– What the system should do
– Each high-level requirement:
● takes in some data from the user
● outputs some data to the user
 Functional Requirements
• Functional requirements will specify a behavior or function
– Describe an interaction between the system and its environment
• Ex: In a library automation system a functional requirement might be search book.

– Transformations (inputs, processing, outputs)

– Data
• Inputs and Outputs
• Stored data
• Transient data

– Exception handling
– Questions addressed by functional requirements have answers that are
independent of a implementation of a solution to the customer’s problem
• Independent of type of programming language, hardware, kind of other resources,
etc.
 Functional Requirements
● F1: Search Book
– Input:
● an author’s name:
– Output:
● details of the author’s books and the locations
of these books in the library.
 Functional Requirements
• Examples:

(i) The user shall be able to search either all of the initial
set of databases or select a subset from it.
(ii) Users should be able to register, log in, and log out
securely from the website.
 Nonfunctional Requirements

● Characteristics of the system which

can not be expressed as functions:
● Maintainability,
● Portability,
● Usability, etc
 Nonfunctional Requirements
• Nonfunctional requirements include:
– Reliability issues
– Restriction on the system that limits choice for
constructing a solution to the problem
• Ex: hardware restriction, constraints (response
time, etc..), implementing techniques…
Nonfunctional Requirements
– Performance issues
• Capacity
– no. of simultaneous users, processing requirements for
normal and peak loads, static storage capacity, spare
capacity
• Response time
• System priorities for users and functions
• System efficiency
• Availability
• Fault recovery
Nonfunctional Requirements
• External Interface requirements
– User interfaces: sample screen layout
constraints, any GUI standards, error
messages, display standards etc.
– Hardware interfaces: description of the
supported device types, communication
protocol etc.
– Software interfaces: describe the connection
between this software and other specific
software components including databases, OS,
libraries etc.
Non-Functional Requirements
Example:
(i) The website should comply with accessibility standards
such as WCAG (Web Content Accessibility Guidelines)
to ensure that it is usable by people with disabilities.
(ii) The system should backup payroll data monthly and
have procedures in place for disaster recovery to
minimize the risk of dat.a loss or corruption
 SRS Standards
• ANSI/IEEE SRS Standard 830-1984
• BS 6719: 1986
• European Space Agency Standards
(ESA PSS-05-0, Jan 1987)
• US DoD-Std-7935A
• ...
 SRS Prototype Outline
[ IEEE SRS Standard ]

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms and Abbreviations
1.4 References
1.5 Overview
 SRS - Introduction Section
• Purpose
– Definition, system overview, and background
– specify the intended audience for the SRS
• Scope
– identify the SW products to be produced by name
– explain what the SW product will do, and if necessary,
what it will not do
– describe the application of the SW being specified. ie.
benefits, objectives, goals as precisely as possible
• Overview
– describe what the rest of the SRS contains
– how the SRS is organized
 SRS Prototype Outline
[ IEEE SRS Standard ]

2. General description
2.1 Product perspective
2.2 Product function summary
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
 Product Perspective
• State whether the product is independent and
totally self contained
• If the product is component of a larger system
then:
– describe the functions of each component of the larger
system and identify interfaces
– overview of the principal external interfaces of this
product
– overview of HW and peripheral equipment to be used
• Give a block diagram showing the major
components of the product, interconnections,
and external interfaces.
 Product Functions
• Provide a summary of functions the SW will
perform
• The functions should be organized in such a
way that they are understandable by the user

User Characteristics
• Describe the general characteristics of the
eventual users of the product. (such as
educational level, experience and technical
expertise )
 General Constraints
• Regulatory policies
• HW limitations
• Interfaces to other applications
• Parallel operation
• Control functions
• Criticality of the application
• Safety and security considerations
 SRS Prototype Outline
[ IEEE SRS Standard ]

3. Specific Requirements
- Functional requirements
- External interface requirements
- Performance requirements
- Design constraints
- Attributes eg. security, availability,
maintainability, transferability/conversion
- Other requirements
Appendices
Index
 Appendices
• Not always necessary
• It may include:
– sample I/O formats
– DFD, ERD documents
– results of user surveys, cost analysis studies
– supporting documents to help readers of SRS
 Example: Functional
Requirements
• List all functional requirements
– with proper numbering.
• Req. 1:
– Once the user selects the “search” option,
• he is asked to enter the key words.
– The system should output details of all books
• whose title or author name matches any of the key
words entered.
• Details include: Title, Author Name, Publisher
name, Year of Publication, ISBN Number, Catalog
Number, Location in the Library.
 Example: Functional
Requirements
• Req. 2:
– When the “renew” option is selected,
• The user is asked to enter his membership
number and password.
– After password validation,
• The list of the books borrowed by him are
displayed.
– The user can renew any of the books:
• By clicking in the corresponding renew box.
 Req.1:
• R.1.1:
– Input: “search” option,
– Output: user prompted to enter the key words.
• R1.2:
– Input: key words
– Output: Details of all books whose title or author
name matches any of the key words.
• Details include: Title, Author Name, Publisher name, Year of
Publication, ISBN Number, Catalog Number, Location in the
Library.
– Processing: Search the book list for the keywords
 Req. 2:
• R2.1:
– Input: “renew” option selected,
– Output: user prompted to enter his membership
number and password.
• R2.2:
– Input: membership number and password
– Output:
• list of the books borrowed by user are displayed. User
prompted to enter books to be renewed or
• user informed about bad password
– Processing: Password validation, search books
issued to the user from borrower list and display.
 Req. 2:
• R2.3:
– Input: user choice for renewal of the books
issued to him through mouse clicks in the
corresponding renew box.
– Output: Confirmation of the books renewed
– Processing: Renew the books selected by the
in the borrower list.
 Quiz
• Identify the types of requirements based on
given below statement:
(i) The user shall be able to search either all of the initial set of
databases or select a subset from it.
(ii) The system should respond to user interactions within 2
seconds under normal load conditions, with a maximum
response time of 5 seconds during peak booking periods.
(iii) The system shall generate a unique identifier (ID) for each
registered patient to ensure data integrity and facilitate record
retrieval.
 Software Engineering
Software Requirements Specification
(SRS) Document
Matthew Seiler
Danielle Paredes
Forrest Meade
Isaac McCraw
Nathan Velasquez

Bowtie Code

www.radford.edu/softeng10
 Revisions

Version Primary Description of Version Date

Author(s) Completed

Draft 0.1 Matthew Seiler, Partial draft including introductory and functional 03/25/14
Forrest Meade requirements sections

Draft 0.2 Matthew Seiler, Pasted in references, performance requirements, and 03/27/14
Forrest Meade, usage scenarios. Added interface requirements, UML
use case diagram, non-functional requirements
Nathan
Velasquez,
Danielle Paredes,
Isaac McCraw

Review & Approval

Requirements Document Approval History

Approving Party Version Signature Date

Approved
Project Manager
Dr. T. L. Lewis

Requirements Document Review History

Reviewer Version Signature Date

Reviewed
Danielle Paredes Draft 0.2 Danielle Paredes 3/27/14

Forrest Meade Draft 0.2 Forrest Meade 3/27/14

Isaac McCraw Draft 0.2 Isaac McCraw 3/27/14

Matthew Seiler Draft 0.2 Matthew Seiler 3/27/14

Nathan Velasquez Draft 0.2 Nathan Velasquez 3/27/14

Bowtie Code 1
 Contents

1. Introduction .............................................................................................................................3
1.1 Purpose of this document ..................................................................................................3
1.2 Scope of this document .....................................................................................................3
1.3 Overview ...........................................................................................................................3
1.4 Business Context ...............................................................................................................3
2. General Description .................................................................................................................4
2.1 Product Functions ..............................................................................................................4
2.2 Similar System Information ..............................................................................................4
2.3 User Characteristics ...........................................................................................................4
2.4 User Problem Statement ....................................................................................................4
2.5 User Objectives .................................................................................................................5
2.6 General Constraints ...........................................................................................................5
3. Functional Requirements .........................................................................................................5
4. Interface Requirements ..........................................................................................................11
4.1 User Interfaces .................................................................................................................11
4.2 Hardware Interfaces .........................................................................................................13
4.3 Communications Interfaces .............................................................................................13
4.4 Software Interfaces ..........................................................................................................13
5. Performance Requirements....................................................................................................13
6. Other non-functional attributes..............................................................................................13
6.1 Security ............................................................................................................................13
6.3 Reliability ........................................................................................................................13
6.4 Maintainability ................................................................................................................13
6.5 Portability ........................................................................................................................14
6.6 Extensibility .....................................................................................................................14
6.7 Reusability .......................................................................................................................14
6.8 Application Affinity/Compatibility .................................................................................14
7. Operational Scenarios ............................................................................................................14
8. Preliminary Use Case Models and Sequence Diagrams ........................................................15
8.1 Use Case Model ...............................................................................................................15
8.2 Sequence Diagrams .........................................................................................................15
9. Updated Schedule ..................................................................................................................15
10. Appendices ..........................................................................................................................15
10.1 Definitions, Acronyms, Abbreviations ..........................................................................15
10.2 References .....................................................................................................................16

Bowtie Code 2
 1. Introduction
1.1 Purpose of this document

The purpose of this document is to provide a detailed description about the requirements
needed to successfully complete the Radford University Agenda mobile application for the
benefit of the project management, client, and development team. Throughout this document,
Bowtie Code will provide a general description of the project, the functional, interface, and
performance requirements for the application, a list of other relevant application attributes,
application usage scenarios, and use case diagrams, as well as an updated schedule

1.2 Scope of this document

This requirements effort intends to define the requirements for the RU Agenda mobile
application. The requirements elicitation team includes Danielle Paredes, Forrest Meade,
Isaac McCraw, Matthew Seiler, Nathan Velasquez, and the client, Mr. Ryan Skipper. The
team will spend the period between March 4, 2014 and March 27, 2014 identifying and
documenting functional, interface, performance, and other requirements for the RU Agenda
software system. Actual time spent on requirements elicitation during that period will be
considerably less than the total 23 days scheduled, as the Spring Break holiday and midterm
exams are included in the same time span.

1.3 Overview

The RU Agenda mobile application is intended to provide Radford University students

with a way to track their class assignments and due dates using their mobile device. The
application will maintain a list of assignments which can be viewed with all assignments in
order by due date or with assignments grouped by class. Each assignment will include a title,
description, class, and due date. The user can add assignments to the list, modify existing
assignments, or select one or more assignments to remove from the list. Additionally, the
app can optionally notify the user a set time before the due date of an assignment,
automatically remove past-due assignments, and automatically download the user’s class
schedule from Radford University’s systems.

1.4 Business Context

The development of this software system is sponsored by the Software Engineering

program in the Department of Information Technology at Radford University. The Software
Engineering concentration is intended to produce designers and developers for large,
complex software systems. The program introduces students to the concepts and techniques
required to build large software systems, and provide opportunities to obtain practical
experience applying those techniques on an actual development effort.

Bowtie Code 3
 2. General Description
2.1 Product Functions

The RU Agenda app will allow Radford University students to access their class
schedules and manage their assignment information through an Android application. The
finished application will provide a way for users to access their class schedule by logging in
to Radford University’s systems, add, remove, and edit assignment info in a list of
assignments, and share assignment information with other users

2.2 Similar System Information

myHomework is a to do app that provides a similar task organization. It is similar in ways

such as listing the current classes you are in, and allowing you to view your assignments by
class and by priority. One advantage that myHomework has is that it allows you to select the
type of assignment. On the other hand, our app will be able to alert users to assignment due
dates and import the user’s class schedule automatically, which myHomework is not capable
of.

Koofers is an online database of class information for universities nationwide, which

allows users to build a class schedule and access class information such as assignments and
exams from past semesters. It has many more features than the proposed RU Agenda
application, such as a GPA calculator and professor ratings. However, the scope of the
website is much larger than the scope of the proposed project; the RU Agenda aims to do few
things but do them well and in a way that will be most convenient for student users at
Radford University.

The Apple iOS Reminders app allows users to associate a list of tasks with an email
account, and create tasks and reminders under that account that can notify the user near
planned completion time. The app boasts quick and seamless integration with iOS on the
iPhone, but is not targeted to student users, and thus is not class-based, cannot import a user’s
class schedule, and does not provide task attributes related to class assignments.

2.3 User Characteristics

The RU Agenda application is intended to be used by Radford University students. A

typical user should have some experience using web applications and mobile operating
systems. A basic knowledge of the iOS or Android operating system on a mobile device as
well as the ability to authenticate to Radford University’s online student services will be
sufficient to use the application effectively.

2.4 User Problem Statement

Although there exist many applications designed to help users manage their schedules
and tasks, there are currently no solutions which are designed specifically for Radford
University students. Other applications require that users manually manage their task
categories and task attributes, whereas an application which is targeted at students and is
integrated with Radford University’s student services would allow significantly more
automation and greater ease of use.

Bowtie Code 4
 2.5 User Objectives

After signing in with my Radford University username and password, the application
should automatically import my current class schedule and any assignments associated with
those classes which have been uploaded by my instructors. The application should allow me
to add new assignments, edit current assignments, and remove old assignments. The
applications should alert me if there is an assignment or test due soon, and should make it
easy to quickly check what assignments are due next and which assignments are due for a
particular class. I should also be able to share the information about an assignment with
another student.

2.6 General Constraints

The application must run on the Android mobile operating system. A user’s Android
device must provide network connectivity (both hardware and software) in order for the
application to fully function. The system must use class data and authentication systems
which are already in place and provided by Radford University.

3. Functional Requirements
Criticality Scale
Non-Critical Non
Less Critical Less
Critical Normal
Very Critical Very
Extremely Critical Extreme

1. The application shall maintain a list of classes for the user

a. Description - The application will store a list of academic class information for
the user. This list should be accessible, editable, and persistent between
application lifetimes. The associated attributes of a class are described in
subsequent additional requirements.
b. Criticality - Extreme
c. Technical issues - The app must use input provided by the user and/or retrieved
from an external web service to create a list of classes associated with the current
user. The app should also be able to store this list in such a way that it is
persistent if the application is terminated and restarted.
d. Risks - Low risk - technical implementation is relatively straightforward and there
is no dependency on network or remote database connectivity.
e. Dependencies - none
2. A class shall include the course title
a. Description - One attribute of a class as stored by the application will be the title
of the course, for example “Web Programming II” or “Software Engineering I”.
b. Criticality - Very
c. Technical issues - This attribute must be generated from either direct user input
or data retrieved from a web service or remote database.
Bowtie Code 5
 d. Risks - Course titles can be verbose - if an attribute must be dropped because of
screen real-estate concerns on the user input form for class attributes, this one will
go first.
e. Dependencies - 1.
3. A class shall include the course number
a. Description - Another attribute of a class is the course number for that class, for
example “ITEC 320-01” or “ITEC 345-02”.
b. Criticality - Very
c. Technical issues - This attribute must be generated from either direct user input
or data retrieved from a web service or remote database.
d. Risks - Low risk - implementation is simple and does not require complex
interactions with other requirements
e. Dependencies - 1.
4. A class shall include the location where the class meets
a. Description - Another attribute of a class is the location where the class meets,
expressed in terms of a campus building and room number, like “Davis 114” or
“Young 123”.
b. Criticality - Very
c. Technical issues - This attribute must be generated from either direct user input
or data retrieved from a web service or remote database.
d. Risks - Low risk - implementation is simple and does not require complex
interactions with other requirements
e. Dependencies - 1.
5. A class shall include the days and times when the class meets
a. Description - Another attribute of a class are the days of the week and times of
the day when that class meets, for example “M W F 10:00am - 11:50am”.
b. Criticality - Very
c. Technical issues - This attribute must be generated from either direct user input
or data retrieved from a web service or remote database.
d. Risks - Non-plaintext data could be more complicated to collect, store, and output
appropriately.
e. Dependencies - 1.
6. A class shall include the name of the instructor who teaches the class
a. Description - Another attribute of a class is the name of the instructor who
teaches the class, for example “Tracy Lewis-Williams” or “Edward G. Okie”.
b. Criticality - Normal
c. Technical issues - This attribute must be generated from either direct user input
or data retrieved from a web service or remote database.
d. Risks - It is highly unlikely that this attribute would need to be removed, but it is
lower priority than the What (3), Where (4), and When (5) attributes and could be
removed if screen space is heavily constrained.
e. Dependencies - 1.
7. Users shall be able to add a class to a list of classes in which they are enrolled.
a. Description - When using the application, any user should be able to add a class
and its corresponding details to the list of classes the application maintains.
b. Criticality - Very
Bowtie Code 6
 c. Technical issues - When the user presses the associated button in the application,
the application should present the user with a form to allow them to add class
details. After adding class details, the app should create a class instance with data
fields corresponding to the user input and add the instance the list of the user’s
classes.
d. Risks - Low risk - technical implementation is relatively simple and there no app-
external dependencies (no network and/or remote database connectivity is
required).
e. Dependencies - 1.
8. Users shall be able to remove classes from the list of classes in which they are
enrolled
a. Description - When using the application, any user should be able to remove a
particular class from their list of classes.
b. Criticality - Very
c. Technical issues - The application should be able to remove the class from the list
of classes which it maintains locally. This change should be reflected into
persistent local storage, but not to any external web service or remote database.
d. Risks - Low risk - implementation is simple and does not require complex
interactions with other requirements
e. Dependencies - 1.
9. Users shall be able to completely reset their lists of classes and assignments
a. Description - This function would allow the user to reset their agenda to an empty
state in between semesters by permanently removing all classes and all
assignments associated with those classes.
b. Criticality - Less
c. Technical issues - The significant data loss associated with this function
necessitates a confirmation prompt at minimum, or perhaps even a temporary
undo capability, but undo capability would drastically increase the complexity of
the function.
d. Risks - Since removing a single class at a time would allow the user to clear all of
their classes and achieve an identical state (simply in a less convenient manner)
this requirement receives a lower priority and could be dropped if development
time is constrained.
e. Dependencies - 1.
10. Users shall be able to authenticate to the application using their Radford University
username and password
a. Description - The system should be able to verify the Radford University
credentials of a user in order to authenticate the user to the university’s web
services.
b. Criticality - Non
c. Technical issues - Precondition: satisfaction of this requirement depends on the
capability to leverage Radford University’s authentication system.
d. Risks - Radford University’s authentication systems are obfuscated from the
development team and may not be accessible in any way.
e. Dependencies - External
11. The application shall be able to automatically download the class schedule of
Bowtie Code 7
 authenticated users
a. Description - The application should be able to automatically import the class
schedule of an authenticated user (see req. 10) for the current semester on request.
Accessing the user’s class data using a web service or remote database would
allow the application to populate the user’s list of classes without taking direct
text input from the user.
b. Criticality - Non
c. Technical issues - Precondition: this functionality depends on the availability of
appropriate external web services and network connectivity.
d. Risks - Depends entirely on 10 and the general capability to access web services
associated with Radford University. The capability is also complex enough that
the team may not be able to implement it in the time available for the project.
e. Dependencies - 1, 10.
12. The user shall be able to view their list of classes
a. Description - The application should provide a list view for the user of all the
classes currently stored by the app.
b. Criticality - Extreme
c. Technical issues - Precondition: App stores a list of class/course instances; Post
condition: graphical presentation of the classes to the user in list format
d. Risks - Low risk - simple implementation and no complicated dependencies.
e. Dependencies - 1. (list must exist to be viewed)
13. The app shall maintain a list of assignments associated with each class in the list of
classes
a. Description - Every class in the list of classes will have another list associated
with it to store assignments related to that class.
b. Criticality - Extreme
c. Technical Issues - Using a user’s list of classes and additional direct user input,
the app can create and store a list of assignments for each class.
d. Risks - Low risk - simple implementation and no complex dependencies
e. Dependencies - 1. (class list must exist to associate assignments with classes)
14. Users shall be able to add an assignment to a list of assignments
a. Description - The application should provide the capability for the user to add a
new assignment to the list of assignments for a class.
b. Criticality - Very
c. Technical issues - Input: Existing class, direct user input. Output: Assignment
instance added to list of assignments for class
d. Risks - Low risk - simple implementation and no complex dependencies
e. Dependencies - 13.
15. Users shall be able to edit assignments in their list of assignments
a. Description - The application should provide the capability for the user to edit the
attributes of an existing assignment in the list of assignments for a particular
class.
b. Criticality - Normal
c. Technical issues - Input: Existing assignment, direct user input. Output:
Modified assignment instance in list of assignments
d. Risks - Low risk - simple implementation and no complex dependencies
Bowtie Code 8
 e. Dependencies - 13.
16. Users shall be able to remove an assignment from their list of assignment
a. Description - The application should provide the capability for the user to remove
an assignment from the list of assignments for a particular class.
b. Criticality - Very
c. Technical issues - Input: List of assignments, user chooses an assignment to
remove Output: Chosen assignment permanently removed from list of
assignments
d. Risks - Low risk - simple implementation and no complex dependencies
e. Dependencies - 13.
17. Users shall be able to clear all assignments for a particular class
a. Description - The application should provide the capability for the user to remove
all assignments from the list of assignments for a particular class with a single
action.
b. Criticality - Normal
c. Technical issues - Input: existing class, direct user interaction. Output: All
assignments for selected class permanently removed
d. Risks - Since removing all assignments can be accomplished by removing
assignments individually, this requirement is lower priority than requirement 16
and might not be completed if development time is constrained
e. Dependencies - 13.
18. The user shall be able to set the name of an assignment
a. Description - One attribute of an assignment should be a name or title for the
assignment (less than 255 characters in length)
b. Criticality - Normal
c. Technical issues - Input: new or existing assignment, direct user input (text).
Output: new name attribute of assignment instance
d. Risks - Low risk - simple implementation and no complex dependencies
e. Dependencies - 13, 14, 15.
19. The user shall be able to set the description of an assignment
a. Description - Another attribute of an assignment should be an optional detailed
description of the assignment (roughly 0 to 1000 characters)
b. Criticality - Normal
c. Technical issues - Input: new or existing assignment, direct user input (text).
Output: new description attribute of assignment instance
d. Risks - Low risk - simple implementation and no complex dependencies
e. Dependencies - 13, 14, 15.
20. The user shall be able to set the due date of an assignment
a. Description - Another attribute of an assignment should be the date and time
when the assignment is due
b. Criticality - Normal
c. Technical issues - Input: new or existing assignment, direct user interaction.
Output: new due date attribute of an assignment instance
d. Risks - Time and date parsing and calculation is reasonable complicated, and the
team might not be able to fulfill this requirement in a satisfactory manner if
unable to use a third-party date picker UI component
Bowtie Code 9
 e. Dependencies - 13, 14, 15.
21. The user shall be able to set the class which an assignment belongs to
a. Description - When creating an assignment or when editing an assignment, the
user should be able to specify which class from their list of classes the current
assignment is associated with
b. Criticality - Very
c. Technical issues - Input: new or existing assignment, direct user interaction,
existing class. Output: sets association between class and assignment
d. Risks - Low risk - simple implementation and no complex dependencies
e. Dependencies - 1, 13, 14, 15.
22. The user shall be able to set notification parameters for an assignment
a. Description - The user should be able to optionally specify a length of time
before the due date of an assignment
b. Criticality - Less
c. Technical issues - Input: new or existing assignment, direct user input. Output:
new notification settings for an assignment
d. Risks - The settings interface should be relatively easy to implement, however the
overall notifications system (req. #26) may be more complex. If the related
requirement is not completed then this feature will be stripped for consistency.
e. Dependencies - 13, 14, 15, 26.
23. The user shall be able to view their list of assignments ordered by due date
a. Description - The application should provide the user with a way to view all of
their assignments for all of their classes together, ordered by due date.
b. Criticality - Very
c. Technical issues - Input: Lists of assignments for every class. Output: Combined
list sorted by due date.
d. Risks - Low risk - simple implementation and no complex dependencies
e. Dependencies - 13.
24. The user shall be able to view their list of assignments grouped by class
a. Description - The application should provide the user with a way to view all of
the assignments for only one class, ordered by due date
b. Criticality - Normal
c. Technical issues - Input: Existing list of assignments for each class. Output:
presentation of the same
d. Risks - Low risk - simple implementation and no complex dependencies
e. Dependencies - 1, 13.
25. The user shall be able to view the detailed attributes of a single assignment
a. Description - The application should be able to present the user with all of the
attributes of one assignment in a single view
b. Criticality - Normal
c. Technical issues - Input: User-selected existing assignment. Output: presentation
of all attributes of the selected assignment
d. Risks - Low risk - simple implementation and no complex dependencies
e. Dependencies - 13.
26. The application shall be able to notify the user when an assignment is close to its due
date
Bowtie Code 10
 a. Description - If the application should be able to present the user with a
notification at the appropriate time if the user has specified that option for a
particular assignment.
b. Criticality - Less
c. Technical issues - Input: Notification attribute of existing assignment. Output:
UI notification of approaching due date.
d. Risks - If the application framework does not provide a mechanism for triggering
UI notifications, then this requirement may not be able to be completed.
Additionally, if implementation of this feature is found to be overly complex then
it may not be completed in the development time allotted for the project.
e. Dependencies - 13, 22.

4. Interface Requirements
4.1 User Interfaces
The interface shows the user notifications for meetings in a personally designed agenda and
allows the user to continually customize their schedule by allowing the user to add events and
classes by a simple touch of the screen. Then the user may customize that event to specific detail
and specification.

4.1.1 GUI
Screen Mockups:

Bowtie Code 11
4.1.2 CLI
N/A

Bowtie Code 12
4.2 Hardware Interfaces
The app is designed for the Android phone and market.

4.3 Communications Interfaces

The application will utilize the networking hardware of the user’s device through network
communications services provided by the Android operating system. Network communications
capability will be used to connect to remote databases and/or web services for authentication and
importing the user’s class schedule information.

4.4 Software Interfaces

None additional

5. Performance Requirements
System
The application will run on all Android devices running 4.1 (JellyBean) or Later. It will be
around 11mb in size. The application will respond to the size of the screen and/or window the
application is running in.

Response Time
The application should take less than 4 seconds when running on an Android phone and less than
8 second when on an emulator or tablet. The application will run fine until the user begins to
multi-task between 3 or more processes.

Workload
The application must support approximately 10,000 users at the time of launch based on the
population of the RU student body.

Scalability
The application will be able to scale to the size of the RU student body as it increases.

6. Other non-functional attributes

6.1 Security
Users must be a Radford University student in order to access the automatic class schedule and
assignment sharing features of this application Users can authenticate by logging in using their
RU username and password.

6.3 Reliability
Most functionality will not require network connectivity. System components that require
authentication through Radford University and network connectivity will function as long as the
systems maintained by the University are available.

6.4 Maintainability
The development team will follow best practices for clean code and software modularity in order
to make the application as maintainable as possible.

Bowtie Code 13
6.5 Portability
Users will be able to access this application on or off campus anytime on their mobile device
without the need of an internet connection.

6.6 Extensibility
The application will be highly extensible in terms of adding course and calendar details or views.
However, the application in general has low extensibility.

6.7 Reusability
An application instance shall be able to be reusable every semester for a returning student. The
user will be able to update their class schedule by having the application check for a registered
schedule set for the next semester and if the current school semester is over. Application
components will be able to be integrated into the larger RU Mobile application developed and
maintained by Radford University.

6.8 Application Affinity/Compatibility

The application shall be compatible with Android 4.1 or any later version.

7. Operational Scenarios
1) Student arrives on campus the day before the semester starts and is informed about the RU
Agenda phone app by a friend. The student then begins to download and install the application
on to his/her mobile device. The student logs in to the application; having already registered for
classes; the application downloads the student’s schedule for them.

2) The semester begins and a new student has recently downloaded the new Radford University
app called RU Agenda. The student is on his way to his to his first class but before he leaves he
checks his RU Agenda app that has automatically downloaded his class schedule from a Radford
database to make sure he is headed to the correct class at the correct time. He logs in using his
new RU login information and notices his class is exactly when he thought and also notices
while maneuvering through the app that he has an assignment due in the class already.
Conveniently he acquires details about the assignment from the app and realizes the assignment
is not due for a few weeks. He carries on to his class as scheduled.

3) During the semester, the student is in one of his/her classes and the professor assigns an
assignment to the class. The student then goes onto RU Agenda to that specific class. There
he/she adds the assignment with its title, description, and due date for the assignment. Then it is
added to the list of assignments for that class conveniently for the student. The student then logs
off and continues listening in class.

4) While working on a homework assignment, the student receives an email from their instructor
notifying them that the due date for the assignment has been postponed. The student had already
added this assignment in their RU Agenda. They navigate to the view of assignments grouped
by class, select the appropriate class, and select the assignment to open a detailed view. From
there they edit the due date for the assignment to the new, postponed due date, and check the
notification settings for the assignment. The next day, after completing the assignment, they
open the RU Agenda app and remove the assignment from their list.

Bowtie Code 14
 8. Preliminary Use Case Models and Sequence Diagrams
8.1 Use Case Model

Log into System

Manage Class

Manage Assignment

User Share Assignment

View Schedule

View Class List

View Assignment
list by due date

8.2 Sequence Diagrams

(Omitted by Instructor)

9. Updated Schedule
(See attached Excel document Project-Schedule.xlsx)

10. Appendices
10.1 Definitions, Acronyms, Abbreviations
“RU” – Radford University
“App” – Application

Bowtie Code 15
10.2 References
“myHomework Student Planner App.” instin, LLC., 2014. Web. 27 March 2014.
< https://myhomeworkapp.com/ >

“Koofers.” Koofers, Inc., 2014. Web. 27 March 2014. < https://www.koofers.com/ >

“iOS: Using Reminders.” Apple, Inc., 2014. Web. 27 March 2014.

< https://support.apple.com/kb/HT4970 >

“Software Engineering.” Dept. of Information Technology at Radford University, 2014. Web.

27 March 2014. < http://www.radford.edu/content/csat/home/itec/programs/
computer-science/software-engineering.html >

Lewis-Williams, Tracy. “ITEC 370 - Software Engineering I - Course Syllabus” 2014. PDF file.

Bowtie Code 16
Requirement Engineering
 Learning Outcome
• After Completing the module student will
be able to understand the techniques for
representing complex logic.
 Specification Languages or
Representation of complex
processing logic
• Requirements specification use some
specification language
• Language should have some desired
qualities
– Modifiability, understandability, unambiguous,
easy to learn and use..
 Specification Languages
• Commonly used languages for
requirement specifications are
– Structured English
– Regular expressions
– Decision Trees
– Decision Tables
– Finite State Automata
Natural Language and Structured
English
• Natural language advantage is both client and
user/supplier understand the language
• Disadvantage is that due to vary nature of
language, written requirements will be imprecise
and ambiguous
• Natural language use in a more structured way :
structured English
– Requirements are broken into sections and
paragraphs
– Many organization specify strict use of words like
“shall, “perhaps”, and should”
 Regular Expression
• String specification
• Useful for specifying things such as input data,
command sequence..
• Used in compiler construction
• Few basic constructs use in regular expressions:
– Atoms: basic symbols or the alphabet of the language
– Composition: formed by concatenating two regular
expressions.
– Alternation: specify the either/or relationship.
– Closure: specifies the repeated occurrence of a
regular expression
 Example
Record File =(Name Reg. no.)
Name= (Last First)
Reg. No = digit digit digit digit
Digit = (0-9)
 Decision Trees

Decision Trees are useful tools for helping you

to choose between several courses of action.
 Decision Trees cont..

• A diagram that presents conditions and actions

sequentially and thus show which conditions to
consider first, which second, and so on
• Method of showing the relationship of each
condition and its permissible actions
• Root of the tree is starting point of decision
sequence
• Force the analyst to consider the sequence of
decisions
 Decision Tree

Fig: Decision-tree sequence of decisions is from left to right

Decision Tree Example

Fig: Decision Tree for Library Management System

Decision Tree
 Decision Tree

Fig: Decision tree for invoice processing

 Decision Table
• Provide a mechanism for specifying
complex decision logic.
• Shows the decision making logic and the
corresponding action taken in a tabular or
a matrix form.
• Table based notation
• Two parts
– Top part of the table lists different conditions
– Bottom part specifies different actions
 Decision Table cont..
• In technical terminology,
– a column of the table is called a rule:
– A rule implies:
• if a condition is true, then execute the
corresponding action.
Decision Table Example

Table: Decision table for Library Management System

Decision Tree vs. Decision Table

● Both decision tables and decision trees

– Can represent complex program logic.
● Decision trees are easier to read and
understand
– When the number of conditions are small.

● Decision tables help to look at every

possible combination of conditions.
 Requirements Validation
• Objective is to ensure that the SRS
reflects the actual requirements accurately
and clearly.
• A related objective is to check that the
SRS document is itself of “good quality”
• Reveal problems in the specifications
• Shortcoming find either in specification or
in problem analysis
 Requirements Validation
• What type of error check :
– Omission
• Some requirements are not included
– Inconsistency
• Due to contradictions within the requirements themselves
• Incompatibility of the stated requirements with the actual
requirements of the client or the environment in which the
system will operate
– Incorrect fact
• Some fact recorded in the SRS is not correct
– Ambiguity
• Some requirements have multiple meaning
 Validation Methods
Requirement Reviews
• Done by a group of people to find errors and
point out other matters of concern
• Primary goal is to reveal any errors in the
requirements
• Review group includes
– Author of the document
– Someone who understand the needs of a client
– Person from the design team
– Person responsible for maintaining the requirement
document
 Requirement Reviews
• Review process also consider factors
affecting quality (testability, readability,
maintainability…)
• Use checklists
• A good checklist depend on the project
type
 Requirement Reviews
• Good checklist generally contains the following
things:
– Are all hardware resources defined?
– Have the response times of the functions been
specified
– Have all the external software, and data interfaces are
specified
– Have all the functions required by the client been
specified
– Are the responses to exceptional conditions specified?
– Does the requirement contain restrictions that can be
controlled by the designer?
– Are possible future modifications specified?
 Quality Function Deployment
(QFD)

Technique that translate the needs of the

customer into technical requirements for
software.
Beginning in Japan in 1966 to help
transform the voice of the customer [VOC]
into engineering characteristics for a product
Quality Function Deployment
(QFD)
• QFD aims to ensure that the voice of the
customer is clearly understood and integrated
throughout the design and development process.
• QFD focuses on maximizing customer
satisfaction from the software engineering
process.
• QFD supports team involvement by structuring
the communication process.
 Quality Function Deployment
(QFD)
• QFD divided the requirement into three categories
– Normal requirements
• Reflected objectives and goals stated for a product.
– Expected requirements
• Implicit to the product or system (fundamental)
• Customer does not explicitly state.
– Exciting requirements
• Beyond customer expectation
• Customer will be very satisfied if present
 Key Elements of QFD
• Voice of Customers: Identifying and understanding customer
needs and expectations. This can include surveys, interviews,
and focus groups.
• House of Quality (HoQ): The primary tool used in QFD, the
HoQ is a matrix that visually represents the relationship
between customer requirements and technical requirements. It
helps teams prioritize features based on customer importance..
• Technical Requirements: These are the specific attributes or
specifications that must be met to satisfy customer needs.
They can include design features, performance metrics, and
compliance standards.
• Prioritization: By analyzing the relationship matrix, teams can
prioritize development efforts on the most critical features that
align with customer needs.
 Example
Project: Smart Home Automation System
Step 1: Identify Customer Requirements (WHATs)
Customer Requirements for Smart Home Automation System
1. Ease of Use: Simple and intuitive interface.
2. Remote Access: Control devices from anywhere via a mobile app.
3. Voice Control: Integration with voice assistants (e.g., Alexa, Google
Assistant).
4. Security Features: Intrusion detection, alerts, and cameras.
5. Energy Efficiency: Monitoring and control of energy usage.
6. Customizable Scenes: Ability to create automated scenes based on user
preferences.
7. Integration with Third-Party Devices: Compatibility with various smart
devices.
8. User Notifications: Alerts for system status and security events.
9. Installation Support: Assistance with setup and installation.
 Example
Project: Smart Home Automation System
Step 2: Identify Technical Requirements (HOWs)
Technical Requirements for Smart Home Automation System
A. User Interface Design: Responsive and user-friendly design
B. Cloud Connectivity: Reliable internet connection for remote access.
C. Voice Recognition Technology: Integration of voice control APIs.
D. Security Protocols: Implement robust security measures.
E. Energy Monitoring Sensors: Devices to track energy usage.
F. Automation Engine: Software to manage customizable scenes.
G. API Integration: Interfaces for third-party device compatibility.
H. Notification System: Real-time alerts and notifications.
I. Installation Guide: Comprehensive setup instructions.
Step 3 : House of Quality (HoQ)
QFD matrix showing relationships between customer requirements and
technical requirements, including strong (5), medium (3), and low (1)
relationships:
Customer Requirements (WHATs) A B C D E F G H I

1. Ease of Use 5 3 1

2. Remote Access 5 3 3

3. Voice Control 5 3

4. Security Features 5 3 5 1

5. Energy Efficiency 5 3 1

6. Customizable Scenes 5

7. Integration with Third-Party Devices 5 1

8. User Notifications 5 3

9. Installation Support 1 5
 Good Requirements Example
• Response time for all level-1 actions will
be less than 100ms.
• 95% of the transactions shall be
processed in less than 1sec.
• MTBF shall be 100 hrs. of continuous
operation.
 Bad Requirements Example
• The system will be fast.
• Errors shall be less than 98%.
• The system shall be maintainable.
• The system shall be completely reliable.
 Keywords
• Requirement Elicitation
– It is a practice of researching and discovering
the requirements of a system from users,
customers, and other stakeholders.
– The practice is also sometimes referred to as
"requirement gathering & analysis “
– Why Elicitation is important?
• Many stakeholders are unable to accurately articulate
the business problem and therefore, analysts
performing the elicitation need to ensure that
the requirements produced are clearly understandable,
useful and relevant.
 Keywords
• Requirement Elicitation Techniques
– Stakeholder Analysis
– Quality Function Deployment (QFD)
– Joint Application Design (JAD)
– Focus Group
– Brainstorming
– Prototyping
Questions?
What is a Requirement?

One of the most critical aspects of Software Product Management deal with conditions
known as requirements. Many definitions have been developed to describe “requirements.”
A requirement is most easily understood as a specific description of your client’s needs,
which can be used to help create a real-world product.

The Institute of Electrical and Electronics Engineers (IEEE) defines a requirement as:

1. A condition or capability needed by a user to solve a problem or achieve an

objective.

2. A condition or capability that must be met or possessed by a system or system

component to satisfy a contract, standard, specification, or other formally imposed
documents.

3. A documented representation of a condition or capability as in (1) or (2). (IEEE,

1990). Well-defined requirements help make sure client needs are understood and
addressed and also help detect potential problems before they become large and
expensive to fix.

Requirement Engineering Activities

will explore five important requirements activities:

1. Eliciting requirements

2. Expressing requirements

3. Prioritizing requirements

4. Analyzing requirements

5. Managing requirements

With these activities, the right requirements can be established, written in proper form,
and even improved.

Eliciting Requirements

The activity of eliciting requirements is an interactive and investigative process, which

occurs when meeting with the client and users.

Clients often have ideas about what features they would like in a product and what these
features should look like. Many clients, however, have limited knowledge of how software is
built and vague ideas regarding what makes a project successful. It can be difficult then for

1
clients to understand what they truly require in a product. It is the role of the software
product manager to help the client figure out what they “want” and what they “need.”

A “want” is usually a functionality or feature that the client would like the product to have,
which may add value, but is not necessarily core to the product itself. A “need,” on the other
hand, is a core functionality that the product must have in order to fulfill the product’s
purpose. Needs should take priority in product development.

The best way to discover and develop “needs” and “wants” with your client is through
eliciting requirements, where you engage in discussion about the product with your client.
Through discussion, the software product manager and team can help provide insights on
what the client “needs” and “wants” the product to do, and how these goals can be feasibly
achieved. It may be that the initial vision the client had of the product will have changed, but
through involvement with the software product team, any changes should feel proactive and
the client should feel reassured that the team understands users’ needs.

Note that eliciting requirements as “needs” and “wants” does not necessarily mean that all
the client’s features and ideas that fall in the “want” category are not doable or should be
dismissed. In fact, these ideas may be very good. But it is the role of the software product
manager to make sure that the goals are feasible, client expectations are realistic, and the
product produced is the best possible result. Eliciting requirements should not be confused
with “requirements gathering.” “Requirements gathering” is the more passive approach of
simply asking the client what they would like done, and it often puts the development team
in a reactive process. Eliciting requirements, however, engages in in-depth discussion and
collaboration from the start of product development, so both the client and the development
team work together to build a successful product.

Expressing Requirements

Once client needs have been established by eliciting requirements, the activity of expressing
requirements comes into play. Expressing requirements involves framing the requirements
identified through discussion in a way that allows a product to be built.

Often, requirements are first described through notes from meetings with clients. From
there, better and more concrete representations can be used for expressing requirements.
Typical representations include use cases, user stories, or storyboards, among others.
These are often tailored to the project. They could be simple or complex, textual or visual. It
is up to the software product manager and team to determine and use representations that
would work best for the project at hand.

Prioritizing Requirements

2
Once a vision of what needs to be done for the project has been established through both
eliciting and expressing requirements, it is important to prioritize client needs, especially in
Scrum methodology.

Questions to help establish priorities include:

• What requirements must be completed for the project and product to be successful?

• What requirements should be done? In other words, what is important but is not as time-
critical or could be satisfied another way or at a later time on the project?

• What could be done to improve the project or product but is not necessary? These
priorities are usually only included if both time and resources allow for it.

The questions outlined here closely follow the MoSCoW method of prioritization, developed
by Dai Clegg. This method is used to help reach an understanding with clients on the
importance of each requirement. “MoSCoW” is an acronym for the categories of “Must
have”, “Should have”, “Could have” and “Would like but won’t get.” By asking the questions
suggested here, requirements can be placed in these.

Analyzing Requirements

The process of examining the listed requirements of a project to ensure that they are clear,
complete, and consistent is known as analyzing requirements. Analyzing requirements
helps ensure that the product is the best one possible. It is an important process, and a
constant one. A project must be continually evaluated and requirements improved as it
progresses. This adaptive nature is important in Agile systems.

Analyzing requirements helps to resolve any potential conflicting requirements or to identify

problems between requirements that might not be easily seen at first glance. It also ensures
that the requirements identified truly reflect and relate to the product being built.

Managing Requirements

The activity of managing requirements is also a continuous process. It involves the

organizing and re-organizing of requirements and possibly reusing subsets of requirements
in different stages. It also involves keeping track of priorities, analyses, and changes in
requirements. This is very important because everything is connected in a project. If
something changes in one requirement, it will affect other requirements and the
development of the product. Managing requirements also means ensuring that the identified

3
requirements are central to the many processes of product creation, including coding,
testing, and change logs.

Types of Requirements

Now that we’ve covered what requirements are and the activities involved with getting them
right, let’s dive into a little more detail and introduce some different types of requirements.
This notes will cover the following types of requirements:

• Business requirements

• Business rules

• User requirements

• Functional requirements

• Non-functional requirements

• External interfaces

• Physical product settings

• Development constraints

While business requirements and business rules can influence the project, it’s user
requirements, functional requirements, and non-functional requirements that are
considered the most essential requirements. Finally, external interfaces, physical product
settings, and development constraints are requirements that add context for design and
implementation of the product.

Business Requirements

There are many possible definitions for business requirements. In this course, business
requirements refer to those requirements that involve the purpose of the project. In business
requirements, goals are presented in concrete and specific terms. These goals are usually
tangible or quantifiable business values that can be used by business analysts.

An example of a business requirement might be: “The client needs to reduce errors in orders
made to their company by 25% by the end of next year to raise their yearly revenue by
$10,000.

Business Rules

Business requirements should not be confused with business rules, although they are often
associated. Business requirements deal with why the project was pursued, while business

4
rules are constraints on how the product will function. Business rules are sometimes
necessary to make a project appropriate or successful. They are often budgets, policies,
guidelines, or regulations. Examples of business rules include:

• Government or legal regulations

• Privacy policies

• Brand uniformity requirement

User Requirements Users or end-users are the people who will use the software once it has
been created. User requirements are the tasks that these users can accomplish with the
product, or what the product can do for the user. User requirements are very important
requirements to the project, if not the most important. They are part of the core functionality
of the product. For this reason, determining user requirements is usually very time
consuming.

There are many methods for expressing user requirements, including:

• Use cases

• User stories

• Storyboards

• Scenarios

Scenarios refer to cases where the client or end-user describes user requirements in their
own words. These descriptions can sometimes be vague or non-specific. It is part of the role
of the software product manager to help organize and refine their needs in more concrete
manners, so the development team knows how to best build the product.

Use cases, user stories, and storyboards are explored in more depth below.

Functional Requirements

Functional requirements are those behaviours that the developed product should do or
support. These are usually expressed as inputs into the product, outputs of the product, or
a description of the behaviour itself. For example, input might be data related to a user’s
online purchase, including name, address, item purchased, and payment information. The
output in this scenario might be a notification email after the transaction is performed.

Often, functional requirements need to be expressed with depth and specificity. Information
flow diagrams are a graphical technique commonly used to show how data flows

5
throughoutthe system and the dependencies of all the system components. Together, an
information flow diagram shows how the entire system functions.

The following is an example of an information flow diagram for a customer using a credit card
with a product, and where the credit card information is verified before a receipt is generated
for the user.

Non-functional Requirements

In addition to functional requirements, there are non-functional requirements that describe

how well a product must perform. They are also known as quality requirements for this

6
reason. Non-functional requirements address product issues including accuracy,
dependability, security, usability, efficiency, performance, and maintainability.

Drawing on the online purchasing example used in functional requirements, a non-

functional requirement in the same scenario would be that emails should be delivered to
users within two hours of purchase. Non-functional requirements are usually
complementary to functional requirements.

External Interfaces

External interfaces requirements refer to those requirements related to how the product is
situated within a larger system. In other words, external interfaces do not concern
themselves with the physical environment of the product, but rather they are concerned with
the relationship of the product to other entities outside the product.

For example, a software application that retrieved information from a remote database to
display to users sits between the entities of the database and the end-user. An external
interface is used between each one. Interfaces also involve the way connections are made
through media, protocols, formats, and levels of compatibility.

External interfaces can be represented within data flow diagrams that show all the
components of a product, including outside entities. These data flow diagrams make explicit
reference to the flow of data from other entities and the product within an entire system.

Physical Setting

Physical setting requirements refer to how the product needs to be designed in order to
function in its physical environment. For example, if a product was being developed for
underwater exploration, it would need to be waterproof. Similarly, if the product was
designed for use in the desert, or in Antarctica, it would need to withstand and function in
those environments.

Development Constraints

Development constraints affect everything from implementation technology, conventions,

documentation, and the process used to develop the product. They generally refer to
constraints related to creating the product, such as which devices or platforms will be
supported, or how much memory, bandwidth, or processing power the product is limited to
using. It is beneficial to address development constraints as late as possible in the
specification phase because technology changes rapidly

7
Client Needs and Software Requirements
Module 2: Client Interactions

User Considerations

When designing a product, one of the most important things to take into consideration is the
end-user. End-users are the people who will use the product. They are among the
stakeholders of the project.

A stakeholder is anyone affected by or who has an effect on the success of the project, such
as end-users, clients, managers of end-users, and system administrators. A successful
project addresses the needs of all stakeholders.

There are three types of stakeholders or users: primary users, secondary users, and tertiary
users.

Primary users are end-users, or the people who will use the product. Secondary users are
those people who will occasionally use the product or use it through an intermediary. They
may not be the target audience, but they could be related to the target audience in some
way, such as parents of children who use a product designed for children. Tertiary users are
those who are affected by the use of the product or make decisions about the product, such
as clients.

A product should be designed to be something users can navigate and want to use. This is
primarily accomplished through good user interface (UI) design. UI is what is seen when
using the product, and it can encompass anything an end-user interacts with—features such
as windows, buttons, scrollbars, checkboxes, and text boxes. Good UI design is important.
If there are many similar products on the market, users will easily move on to another

1
product if they do not like what they are currently using. An entire discipline known as human
computer interaction (HCI) studies how end-users interact with technology products.

A number of issues that may arise in considering user interactions include:

• Users have an inability to express what they need

• Users are biased by previous experiences; e.g., a user is more likely to use a bad
interface that they are familiar with rather than a new one, even if the newer one is
actually a better product
• Developers sometimes have trouble seeing through a user’s point of view because of
their advanced knowledge of technology.

Creating an intuitive, user-friendly interface is key to addressing many of these issues. A

good strategy to consider is to design a product for both beginner users and expert users.
In general, the design will then accommodate intermediate users as well.

When designing software, it is also important to consider the numerous limitations users
are faced with. These limitations are related to human limitations. They include:

• Perceptual or sensory limitations, which are caused by restrictions of the five

senses. Colour blindness is an example of a sensory limitation.
• Physical limitations, which affect how a user physically interacts with or uses a
product. An example is left- or right-handedness.
• Cognitive or memory limitations, where people can only remember so many
things at once, so it is important to use visuals in design that are familiar or
suggestive to help identification.
• Cultural limitations, which encompass how different cultural backgrounds of
potential users can affect interpretation of design elements, such as symbols and
icons, layout, multimedia, and translation needs.

2
 Involving Clients and Users

In Eliciting Requirements, the importance of involving clients was emphasized. A good

software product manager and development team do not simply gather ideas from
clients but actively collaborate with clients. Consequently, client ideas may change from
the outset of discussions, but with input from both the team and the client, the best
possible product can be made.

Requirements can also come from other sources, including:

• Interviews with end-users

• Feasibility studies with focus groups
• Observing how end-users use the product
• Consulting previous products

Involving clients in collaborative discussion over requirements, usually in face-to-face

meetings, helps manage client expectations. By being involved in discussion, clients are
aware of realistic goals and timelines, what will and will not be done in the product, and
subsequently they can prioritize requirements.

Below are some key points to remember when interacting with clients.

Try to keep a good balance between being assertive and open to client ideas and
perspectives. It is not good to just accept ideas passively. The software product manager
and development team should suggest ideas and perspectives in meeting with the client,
but they should not enforce their viewpoints aggressively.

The software product manager should try to provide structure in conversations with the
client about requirements. This will help the client organize his or her thoughts. Care must
be taken not to steer the client, however.

Clients sometimes come with set ideas about what they want in a product. However, they
sometimes don’t know what is possible technically, or they have ideas that would actually
be hard for end-users to understand or use. The software product manager should try to
understand why the client has set upon these ideas. A good way to do this is to ask the client
to explain how they envision an end-user interacting with the product. Once the client’s
reasoning is understood, alternative ideas can be suggested. It may also be useful to politely
highlight why certain ideas may not work. This can also be done through exploring limitations
and different scenarios.

Note that it is the role of the software product manager to make sure a client is well informed
and understands their options. However, at the end of the day, the client is the one who

3
makes the key decisions regarding requirement, even if the development team would prefer
to go a different route.

Requirements should be revisited often with the client. After a first meeting, for example, it
is a good idea to show the client mock-ups and prototypes produced from initial
discussions. With these concrete tools, clients can more readily identify what they like in a
product, what they want, and what they dislike. Revisiting requirements also allows clients
to answer questions, advise on design choices, and provide feedback.

An important tool for interacting with clients is the use and creation of a glossary. A glossary
is a list of terms and their definitions that relate specifically to the product being built. It is
common for many different terms to be generated for the same thing if a glossary is not used
and agreed upon, which can make discussions confusing.

In summary, key aspects to remember in customer interaction include:

• Involve the client through meetings and continuous re-visitation of requirements.

• Use other information sources, such as end users.

• Ask good questions.

• Be assertive and open in client interactions.

• Clearly communicate realistic requirements and timelines to manage client expectations.

• Use common terms via glossaries.

4
• Keep track of requirements

• Remember that it is the responsibility of the software product manager to clearly

communicate the pros and cons of requirements, but the client is the one who must make
the key-level requirement decisions.

Use Cases

Use cases, developed by Ivar Jacobson in 1986, are a good tool for understanding a product.
They can be defined as a way to identify, clarify, and organize details of a task within a
product. Uses cases take place in particular environments to achieve particular goals. In
other words, it’s a way of explaining a set of sequential interactions users might have with
the features of a product.

A good use case outlines the proposed task from the point of view of a participating actor
(usually a user), and it should not require deep knowledge of technology to understand. Use
cases may be presented in tables as outlined below

5
6
For example, a completed use case would look like:

It is helpful to depict the use cases of a product with a diagram (see below). Use case
diagrams are high-level, visual representations outlining all the tasks supported by the
product being created. Actors and their respective uses cases are also represented. Overall,
the diagram should show the entire product, tasks that may be undertaken while engaging
with the product, and roles supported by the product

7
Use cases are a useful tool for software product managers and their development teams
when establishing requirements. By creating use cases and sharing them with clients, the
project has more definite guidelines, and development tasks become more organized and
elaborate.

Wireframes

One of the most important techniques of product development is the use of wireframes. A
wireframe, also known as a mock-up, can be thought of as a kind of early blueprint. It is a
basic visual representation of the product. See the example below of what a biography web
page might look like

8
Wireframes are used for many purposes. These include:

• getting an idea for what will be developed

• demonstrating ideas to clients or users and encouraging their feedback and involvement

• communication among the development team

• helping the client or users communicate with the software product manager and team
(some people may find it easier to sketch out their ideas to describe them).

Although a visual representation, a key aspect of wireframes is their simplicity. Wireframes

are not meant to be a demo of the interface of a product but rather outline basic
functionalities and end-user tasks. This means that wireframes do not use colours or
images. In fact, it is important that detailed design features do not creep in to wireframes.

Instead, wireframes may suggest things like where buttons, text fields, and images are
placed. The elements displayed should theoretically allow a user to do a task with the
product. As in a blueprint for a house, for example, details such as wall colours or lighting
fixtures are not outlined. Later, detailed user interface (UI) design can develop further.

Wireframes are usually developed quickly after an initial discussion with the client regarding
requirements and presented thereafter. Clients then have a chance to see an early version
of what their product might look like and provide feedback. It also ensures that both the
client and development team are working towards the same vision.

9
Storyboards

Another technique used to help in forming requirements are storyboards. Many disciplines
make use of storyboards. In software development, storyboards are sequential, visual
representations of an interaction with the software product.

There are two main types of storyboards. Both types can be helpful for discussions between
clients and the development team. Storyboards help to elicit further requirements of the
product and refine existing ones.

The first type of storyboard describes high-level user experience with the product. This type
of storyboard tends to look like a comic strip, where each action is illustrated in the
sequence or flow of using a product, including the decision to use the product and outcomes
at the end of an interaction. If multiple features are offered in the product, then each should
get a storyboard.

An example of this first type of storyboard appears on the following page.

10
Captains in the panels should read:

1. The Smith family decided to go to Brampton’s Pizza for a nice family dinner.

2. They are seated at a table and use the tablets at the table to browse the menu.

3. They browse the dishes on the application and place their order.

4. The cooks in the kitchen receive the order.

5. The food was delivered to the table once it was read and they have a nice family dinner.

6. Once they were finished their meal, the mother viewed and paid for the bill on the
application.

Generally, the envisioned user, or participating actor (as described in use cases) in this type
of storyboard, is given a persona. Personas provide more elaborate back stories to the
participating actors, including details such as age, ethnicity, income level, job, personality,
etc. Providing high-level details helps the storyboard address specific issues.

The first type of storyboard has many potential uses, including:

• Ensuring the entire development team is on the same page

11
• Enhancing the possibility of identifying features to improve or create in the software
product • Ensuring the vision of the product remains clear in its use

• Use in marketing or demos

The second type of storyboard combines wireframes and basic flow from use cases in order
to show how the end-user interacts with the user interface of the product in detail. It is more
closely related to software design.

It also shows all the sequences of user interaction with the product, and the outcomes of
those interactions. Each state of the product during interaction is illustrated with a
wireframe. The user interface element needed to get to the next state is also illustrated.
Transitions between states are generally depicted with an arrowed line.

The second type of storyboard has many potential uses, including:

• Helping the development team to design requirements

• Helping identify what could be overly complicated or missing in supporting tasks

the users perform

• Ensuring the development team is aware of the functionalities and feel of the

product .

• Guiding technical writers in creating training materials

Below is an example of the second type of storyboard.

12
13