SENG8060
Developing Quality Applications
Winter 2024
2.0 Software Requirements Analysis
2.1 Recognize the role that software requirements and specifications
play in software development.
2.2 Differentiate between functional and non-functional
requirements for a computer application.
2.4 Analyze software requirements and specifications for
completeness and correctness.
Software Requirements is the area within software
development that concerns itself with the definition,
specification, analysis and validation of requirements pertaining
to software development.
Without any requirements, we would have no idea on what we
need to develop (and test).
Also, poor requirements often leads to projects that have poor
quality or projects that fail.
Provide a communication avenue between what the customers
want and the developers / testers who implement the
application
Software Requirements also helps to define the scope of any
software development project / activity to solve a problem.
Requirements also need to managed at every stage of a
software development project / activity to ensure that the
requirements are still indeed correct and valid.
Requirements need to be set up front and for the most part,
cannot change when using the Waterfall model.
Requirements
Design
Implementation
Verification
Maintenance
Can take the form of:
System Requirements
Prototypes (POCs)
Use Cases
User Stories
As requirements change (which they often do), these changes
can be incorporated easier into the development cycle.
The first step involved in developing requirements is to seek
them out using the following sources:
SME’s: Subject Matter Experts
Domain knowledge
Stakeholders within the company
Business Rules
Operational Environment
Customers / Customer Facing Individuals
Techniques need to be used to further develop Requirements:
Interviews / Hall Testers
Scenario simulations
Proof Of Concepts
Prototypes
Brainstorming Meetings
Competition Analysis
User Stories
This technique is mostly used within Agile and take the
vantage point from the various types of users that will be
using the system
For instance, a standalone application such as a Calculator, we
would only have one user (called “The User”) and we would
base our user stories using the following format:
As a <role>, I want <goal> so that <benefit>
User Stories in Agile can essentially replace the requirements
from Waterfall methodologies – they are really a well
expressed and contained requirement
They focus more importantly on the actual role or the user
who will be using the application
They define and provide insight into the true reason why the
requirement is required (i.e. performing Validation)
As a User, I want to be able to add two numbers so that I can see the
correct result;
As a User, I want to be able to subtract two numbers so that I can see the
correct result;
As a User, I want to be able to multiply two numbers so that I can see the
correct result;
As a User, I want to be able to divide two numbers so that I can see the
correct result.
Develop a set of User Stories for an application that would
allow a student to enroll into a course here at Conestoga.
This same application would provide an administrator with
the ability to create new courses as well as to perform
maintenance on them.
Students need to also meet certain pre-requisites to be able
to register for a course.
When we talk about “Functional Requirements”, we are most
interested in HOW the software should function.
For example, with our Calculator application, we want the software
to correctly show the results of every calculation.
When we refer to the “Non-Functional Requirements” of an
application, we are normally referring to those requirements
that are used to CONSTRAIN the application behavior
For example, we want to assess the performance of an app to
determine the load it can handle.
Examples of Functional Requirements:
The program must be able to calculate the addition, subtraction,
multiplication and division of two integers
Upon entering a valid userid and password, the system authenticates the
user and allows them to see their credit history
Examples of Non-Functional Requirements:
Performance
Maintainability
Security,
Etc…
The software products that we develop may consist of many
moving parts – each with its own set of functions that
contribute to the overall system.
To be able to design, develop, implement and test our
product, we need to know exactly how these parts co-exist
and the details around the overall operation – this is what is
known as Requirements Analysis.
By analyzing requirements, we can:
Detect and resolve any inconsistencies between requirements;
Discovery any limitations associated with the software application;
Further elaborate / define the system requirements to properly support the software
related requirements
For this to work effectively, we need to ensure that the requirements we define
are described with enough precision and accuracy to enable them to be
validated as well as their implementation to be verified (remember the ‘V’
model)
Also need to ensure that the requirements are not too detailed that we get lost
in the details and are unable to see the overall product from them.
Requirements can be classified by whether they are:
Functional vs. non-Functional
Derived from higher level requirements
Product or process / workflow related
Of a certain priority for the customer
Constrained by scope
Volatile or changing
Develop a set of Requirements / Specifications using the template provided in eConestoga for this
week.
Due on Friday of this week at the end of the Lab (i.e. 2:00PM)
One submission per group / team
Worth 10% of your overall mark – deductions will apply for any late / absentees
Need to include:
Purpose
Overall Description
System Features
External Interfaces
Non-Functional Requirements
References Used
Any questions?
