Functional and Non Functional Requirements
Summary
TLDRThis transcript provides an overview of functional and non-functional requirements in system design. Functional requirements describe what a system should do, while non-functional requirements focus on how the system performs. It emphasizes the importance of clarity, testability, and feasibility in requirements, using user stories and the INVEST acronym for agile development. The script also discusses non-functional aspects like security, performance, scalability, and maintainability, and introduces tools like the requirements traceability matrix to track progress and ensure that the system meets its intended goals.
Takeaways
- 📝 Functional requirements specify what a system should do, focusing on inputs, behaviors, and outputs.
- 🔍 A good requirement is unambiguous, testable, feasible, independent, traceable, necessary, and implementation-free.
- 📚 User stories can be broken down using the INVEST acronym: Independent, Negotiable, Valuable, Estimable, Small, and Testable.
- 📱 An example of a user story is developing an iPhone application for issuing school permission slips.
- 📈 Non-functional requirements describe the quality of the user experience and system properties without altering functionality.
- 🔑 Security, performance, availability, and accessibility are examples of non-functional requirements.
- 🌐 Accessibility requirements ensure that systems are usable by people with disabilities, such as color blindness.
- 🛠️ Non-functional requirements also include system architecture, technology stack, and network considerations.
- 📊 Requirements can be categorized into must-haves, wants, and assumptions to prioritize and manage them effectively.
- 📋 A requirements traceability matrix helps maintain a master list of requirements and track their status and testing.
Q & A
What are functional requirements?
-Functional requirements refer to the specific functions of a system or component, detailing the inputs, behaviors, and outputs, and clearly stating what the system should do.
What are the characteristics of a good requirement?
-A good requirement should be unambiguous, testable, feasible, independent, traceable, necessary, and implementation-free.
What does the INVEST acronym stand for in the context of user stories?
-INVEST stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable, which are the characteristics that user stories should possess.
How can user stories be used to develop requirements for an iPhone application for school permission slips?
-User stories can be written from the perspective of different users, such as 'As a principal, I want to run a report that identifies all completed permission slips so I will know which students can go on the field trip.'
What are non-functional requirements?
-Non-functional requirements describe the qualities or attributes that the product must have, such as performance, usability, and security, without altering the product's functionality.
Why are non-functional requirements important?
-Non-functional requirements are important as they help to describe the user experience and ensure the system meets certain standards of quality, even though they do not directly contribute to the system's functionality.
What is a common format for writing user stories?
-A common format is 'As a [user role], I want [functionality] so that [value/benefit].'
How do non-functional requirements differ from functional requirements?
-Non-functional requirements focus on the quality and constraints of the system, such as performance and security, while functional requirements specify what the system should do.
What are some examples of non-functional requirements?
-Examples include response time, system capacity, data security, legal compliance, and system availability.
How can a requirements traceability matrix help in managing requirements?
-A requirements traceability matrix helps maintain a master list of all requirements, tracks their status, and links them to test cases, ensuring that all requirements are delivered and tested as planned.
What are the categories of non-functional requirements mentioned in the script?
-The categories include performance, availability, maintainability, capacity and scalability, and recovery.
Outlines
📝 Understanding Functional and Non-Functional Requirements
This paragraph discusses the distinction between functional and non-functional requirements in software development. Functional requirements specify what a system should do, focusing on inputs, behaviors, and outputs, and are often the main focus of development. They should be clear, testable, feasible, independent, traceable, necessary, and implementation-free. Non-functional requirements, on the other hand, describe the quality of the user experience, such as performance, security, and usability, without altering the product's functionality. The paragraph also introduces the concept of user stories, which are a way to capture functional requirements in a format that is independent, negotiable, valuable, estimable, small, and testable. An example of user stories for an iPhone application for school permission slips is provided, illustrating how these stories can be used to manage and implement requirements.
🔐 Non-Functional Requirements: The Backbone of Quality
The second paragraph delves into non-functional requirements, emphasizing their importance in defining the user experience and system properties. These requirements cover aspects such as response time, system capacity, service level agreements, security, legal compliance, and architectural design. It discusses how non-functional requirements guide the system's performance, availability, maintainability, capacity, and recovery. Examples include password policies, accessibility standards, uptime requirements, and data handling practices. The paragraph also touches on the organizational and change management aspects of system deployment, such as training and support, highlighting the need for these requirements to ensure the system's successful adoption and operation.
📊 Managing Requirements with Traceability and Prioritization
The final paragraph addresses the management of both functional and non-functional requirements through the use of a requirements traceability matrix. This tool helps maintain a master list of all requirements, track their status, and link them to test cases, ensuring that each requirement is verified and delivered as expected. The paragraph introduces the concept of categorizing requirements into 'musts,' 'wants,' and 'assumptions' to prioritize and manage them effectively. It also discusses the importance of considering various aspects of system operation, such as maintenance windows, application location, network latency, and restoration times, to ensure that the system meets business needs and user expectations.
Mindmap
Keywords
💡Functional Requirements
💡Non-functional Requirements
💡User Stories
💡INVEST Acronym
💡Traceability
💡Product Backlog
💡Assumptions
💡Must, Wants, and Wishes
💡Requirements Traceability Matrix
💡Performance
Highlights
Functional requirements specify what the system should do, focusing on inputs, behaviors, and outputs.
Good requirements are unambiguous, testable, feasible, independent, traceable, necessary, and implementation-free.
User stories are a way to document requirements, following the INVEST acronym: Independent, Negotiable, Valuable, Estimable, Small, and Testable.
User stories should be independent and negotiable to allow for flexibility in development.
Valuable user stories ensure that the implemented business requirement makes sense for the organization.
Estimable user stories are crucial for planning and should be broken down into smaller requirements if estimation is difficult.
Small user stories are beneficial for developers to understand and implement effectively.
Testable requirements are essential, and if a requirement cannot be tested, it should be revised.
An example of writing user stories for an iPhone application involves permission slips for field trips.
Non-functional requirements describe the quality of the user experience and system properties without altering functionality.
Non-functional requirements are often described using adjectives, such as response time and capacity.
Security, legal, and regulatory requirements are examples of non-functional requirements that impact the system.
Accessibility is a key non-functional requirement, ensuring the system is usable by people with disabilities.
Availability requirements specify system uptime and maintenance windows, ensuring service continuity.
Maintainability considers the ease of software development, coding standards, and frameworks used.
Recovery requirements plan for system restoration and backup processes in case of data loss.
Requirements can be categorized into musts, wants, and assumptions to prioritize and manage them effectively.
A requirements traceability matrix is a tool to track and log the status of requirements and associated test cases.
Transcripts
I want to continue our discussion about
requirements and requirements management
by giving an overview of functional and
non-functional requirements when you
hear the term functional requirements
this refers to a function of a system or
component it looks to the inputs
behaviors outputs it specifically says
what the system should do these are
typically the requirements that you've
been developing in this course when you
think about what makes a good
requirement it's helpful that it's
unambiguous so it's clear and easily be
easily understood it's testable it's
clear understandable the requirement is
actually feasible it's independent
traceable necessary as well as
implementation free often as IT
professionals we try to specify the
requirement in a way that determines how
the requirements should be implemented
but really we're trying to develop the
business requirements that speak to just
the main business need the
implementation on that business need is
up to the systems analysts and the rest
of the development team to determine
another way that we document
requirements the solace in previous
chapters was using user stories and user
stories can be broken down into the
invest acronym and invest stands for
independent negotiable valuable
estimable small and testable so as we
start developing user stories we want
the requirements to be independent so
each story can stand on its own we
should also be able to negotiate these
stories as you come up with large
requirements we need to be able to split
those stories and negotiate as to what
actually goes into a story rather than
creating a different story with these of
these stories we want to make sure that
they are indeed valuable so we're
actually implementing a business
requirement that makes sense and we need
to be able to estimate them if you can't
estimate it's gonna be a difficult
difficult to work with that user story
so you should look to further split
those user stories into smaller
requirements to a point that the team
can actually estimate how long it will
take to turn that requirement into a
working software solution
we'll also a big fan of making sure
these user stories are small having
small concise requirements are helpful
to a developer so they can actually
understand what requirement they're
trying to develop and the culmination of
those small requirements will lead to a
larger functioning system and of course
the requirement needs to be testable if
you can't actually test the requirement
you need to go back in and review and
revise how that requirement could be
written so it could indeed be testable
so here's an example how you can write
some user stories let's say you're going
to develop an iPhone application and you
want to enable a school permission slip
so in this case the instructors and the
students they need to be able to issue a
permission slip for a field trip
once that parent signs the permission
slip using the application the principal
will run a report identifying the
different completed slips and missing
parents approval and you can use this in
a couple different ways one of the most
common formats for user stories is you
can say as a user I want a specific
function so that it provides whatever
the certain value is going to be so in
this example one user story could be as
the principal I want to run a report
that identifies all the completed
permission slips so the students so I
will know what students go on the
specific field trip you could also write
our user story as says as a principal I
want to run a report that identifies the
incompleted
permission slips so I can identify which
students are missing parent approval
those are just two different examples of
how you can do this but as you develop
these different requirements and
different features they become backlog
items in your product backlog so
depending on how you approach your
systems analysis and design you will be
adding requirements to a document or
adding requirements to a product backlog
for those of you that you went through
the Trello example you've seen how we
built out the backlog of requirements in
our Trello list and from there we'd be
able to pick those requirements and
actually implement them then of course
we get into non-functional requirements
non-functional requirements are
important elements to consider
because they all speak about the
property is that the product must have
so these help to describe the experience
the user has while doing the work now
they're called out in a way that you
know their customer wants but also need
to be performed in a certain manner now
it's also important to notice that they
don't alter the products functionality
the functional requirements help
describe what they want to have happen
and the non-functional requirements will
help describe the experience the user
has while doing the work you can see
this file using adjectives as a way to
describe how the system should work so
for example when you use that website
you want to make sure the response time
responds in a timely manner so you can
have a functional requirement that says
the website loads within two seconds or
when you process a form you get a
response within a two-second time sign
at a time frame you may also have to
specify the capacity of the system how
much disk space is needed how much how
are you gonna plan for growth of the
system as you add more users to it what
about service level agreements when you
actually just launched a system how are
you gonna ensure that the system will be
kept up and running and if you have an
external vendor managing the system for
you what service level agreements are
you gonna be putting into place how many
Tayna Balazs the system we all want her
data to be secure so what type of
security goes behind those systems how
are you managing the system what about
legal and regulatory requirements and
then we get into the actual architecture
layers of how's the application built
what's the underlying data architecture
what about the technology stack and what
about the network architecture all these
become non-functional requirements that
you need to start identifying then even
think about how you're gonna roll out
the system it gets in a little bit of
organizational design and change
management training is often a key
deliverable out of a system but those
form their own set of requirements that
are gonna be needed to help roll out the
system and communicate to your target
audience
also thinking about support and
maintenance how usable is the system
where is the system actually located how
are you gonna deliver deploy the
application what about development
standards as well as overall software
configuration management
thinking through where you're going to
store your code how the code is going to
be developed these are all
non-functional requirements that they
don't impact
well they do impact the usability of the
application but they're not specifically
stated in the form of a function that's
going to deliver a direct business value
but if you don't have these
non-functional requirements thought of
you can definitely impact the quality of
your application so let's look at the
security example employees shall be
forced to change their password the next
time they log in if they have not
changed it within the length of time
established as the password expiration
duration password should never be
viewable at any pet the point of entry
or any time within the system the access
permissions for the system data may only
be changed by the system administrator
these are all business rules that need
to be baked into the system but you see
none of these rules end up delivering a
functional component such as I'll
develop a report but or but it will see
the example here that you're using this
to find a way to determine what your
password rules should be so in this case
you got to change your password next
time so these are all go into
requirements that build out those
modules accessibility this is an
important one within the system the
system needs to be accessible to people
with disabilities in accordance with
American with Americans with
Disabilities Act of 1990 accessibility
and websites is becoming more and more
popular topic as we want to make sure
that everybody can view data within our
websites even if they have a disability
as we need to make sure we were writing
code appropriately for the target
audience the system shall be accessible
by people who are color blind to the
extent that they should be able to
discern alt text and all the other
information displayed by the system as
easily as a person without color
blindness it's a key feature because
folks with color blindness actually
still buy a lot of products online
availability the online payment system
shall be available for use between the
hours of 6:00 a.m. and 11:00 p.m. the
system shall achieve a 99.5 percent
uptime these are all requirements that
still need to be considered as you're
building out your application although
it may not
correctly specify a feature that a
business user will perform so when you
look at non-functional requirements that
you run in for every application you can
this is divided across a number of
different categories including
performance availability maintainability
capacity and scalability and recovery so
often we look at response times
processing times when you're running a
report how fast should a report run you
know if you run a large report or a
large query what's the expected time
that the business user will accept
before they start complaining and saying
that the system's not usable when you
think about capacity and scalability how
many transactions can the system handle
what happens if you receive thousands of
orders all at once however you are you
ensuring you're scaling your application
and only think about your data how much
data will be stored where will you store
it and how will that that data be
encrypted it's very important in today's
day and age as more of our personal
personally identifiable information is
brought out to the web that we know how
that data is being handled as well as
how is it being stored and encrypted
given all the different data leaks that
we've seen in the organization
availability is also a concern what are
the specific hours of operation when can
the system actually go down for
maintenance and where's the location of
the application if you have your server
located in North America but your users
are over in Europe how are you ensuring
that the application is available and
there is a network latency that can
impact the performance of the system you
can but maintainability are we
developing the software using standard
solutions or are these one-offs that are
developing software in a language that
only a few people understand think about
the coding standards as well what
language and what coding frameworks are
being used and a big one too is recovery
so you think of restoration time how
long before the applications backup as
well as backup time how long do you
backup the data because you need to be
able to understand how long does it take
the nolley and restore the application
but if you were to restore a days worth
of data would that be sufficient to
maintain your business process or do you
need data to be restored up to the very
hour or the half hour all those form and
requirement
that the application team needs to
determine while they're building their
system another way of viewing
requirements too is when you look at the
must wants and absorption and
assumptions so all requirements be them
functional or non-functional they can be
freely deposed into musts wants and
assumptions so a must is clearly a
time-critical requirement that must be
achieved or delivered within the current
lease of the solution other requirements
are watts it's a requirement that's
wished for but it can be deferred until
a later release so in agile terms or in
using scrum we think of this as a
separate user story please remember we
want to break down those requirements
into smaller chunks so we can deliver
accordingly and an assumption it's the
expectation on part of the project team
now these may include other dependencies
and other project teams timing
considerations or just overall
characteristics that you are making
assumptions about and how the system is
actually going to function now another
way to view all your requirements is by
using a requirements traceability matrix
and the requirements traceability matrix
it's usually in the form of an Excel
document or a table and allows you help
maintain a master list of all the
requirements and the other pieces allows
you to start identifying all the test
cases that need to be written to verify
those requirements are being achieved so
then you can track and the log when you
track the status of each requirement and
how often have the requirements been
tested reviewed and ensure that the
application is functioning as desired
because in a system implementation you
can generate hundreds of different
requirements but if you don't track
those requirements how are you ensuring
requirements are delivered on time this
is an example and the link is here in
the the deck but it's a simple Excel
document where you've got technical
assumptions functional requirements
what's the status and you can actually
list links to the architecture document
the technical specification the system
components but you see here under the
column a software module and test case
number those are two key attributes to
identify the requirement as well as the
test case
that is used to ensure that the system
is properly tested in functioning
تصفح المزيد من مقاطع الفيديو ذات الصلة
Software Requirements | Requirement Engineering | Feasibility Study, Elicitation, SRS, Validation
ISTQB FOUNDATION 4.0 | Tutorial 15 | Test Levels | System Testing | CTFL Tutorials | TM Square
Uber System Design | Ola System Design | System Design Interview Question - Grab, Lyft
SARCH20 V2C 2021 04 15 Module 1 deel 1 van 3
How to solve capacity estimation problems faster? | Thumb rules and quick tips | System Design
Requirement Classification - 4 different types of requirements you need to know!
5.0 / 5 (0 votes)