Functional and Non Functional Requirements

Summary

This 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

00:00

📝 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.

05:01

🔐 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.

10:02

📊 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.

Keywords

💡Functional Requirements

Functional requirements refer to the specific functions that a system or component must perform. They define what the system should do in terms of inputs, behaviors, and outputs. In the context of the video, functional requirements are the core of what is being developed and are often unambiguous, testable, and implementation-free, focusing on the main business needs without dictating how they should be implemented. An example from the script is the requirement for an iPhone application to enable instructors and students to issue a permission slip for a field trip.

💡Non-functional Requirements

Non-functional requirements describe the qualities or attributes that a product must have, such as performance, security, and usability. They do not alter the product's functionality but ensure that the system meets certain standards of quality and user experience. The video emphasizes that non-functional requirements are crucial for defining the user experience and include aspects like response time, capacity, security measures, and legal compliance.

💡User Stories

User stories are a way of documenting requirements from a user's perspective. They are typically written in a simple, everyday language and follow the INVEST acronym: Independent, Negotiable, Valuable, Estimable, Small, and Testable. The video explains that user stories should be independent, allowing each story to stand alone, negotiable to adapt to changing needs, valuable to the business, estimable to be sized for planning, small to be easily understood and developed, and testable to verify that the requirement is met. An example given is a user story for a principal wanting to run a report identifying completed permission slips.

💡INVEST Acronym

INVEST is a set of criteria for creating good user stories. It stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. The video uses this acronym to illustrate how user stories should be crafted to ensure they are clear, manageable, and valuable to the business. Each letter of the acronym represents a quality that helps in breaking down requirements into manageable and testable units.

💡Traceability

Traceability in requirements management refers to the ability to track the requirements from their origin through to delivery and beyond. It ensures that all requirements are accounted for and that changes can be managed effectively. The video mentions the use of a requirements traceability matrix, which is a tool for maintaining a master list of all requirements and linking them to test cases, architecture documents, and other relevant artifacts to ensure that the system is tested and functions as intended.

💡Product Backlog

A product backlog is a list of all the work that needs to be done for the product, including both functional and non-functional requirements. In the video, it is mentioned that as requirements are developed, they become backlog items that are prioritized and selected for implementation. The product backlog is a dynamic tool that helps in managing and organizing the development process, especially in agile methodologies.

💡Assumptions

Assumptions are expectations or presuppositions made by the project team about the project's environment, constraints, or other factors that may affect the project. The video highlights that assumptions can include dependencies, timing considerations, or characteristics of the system's functionality. These assumptions are important to document and manage because they can influence the project's direction and outcomes.

💡Must, Wants, and Wishes

In the context of requirements management, 'must,' 'wants,' and 'wishes' categorize the priority and necessity of requirements. 'Musts' are critical requirements that must be met, 'wants' are desirable but can be deferred, and 'wishes' are nice to have but not essential. The video uses this categorization to discuss how to prioritize requirements and manage the scope of a project effectively.

💡Requirements Traceability Matrix

A requirements traceability matrix is a tool used to track and link all requirements to corresponding test cases, ensuring that each requirement is tested and verified. The video provides an example of how such a matrix can be structured in an Excel document, with columns for technical assumptions, functional requirements, status, and links to architecture documents and test cases. This matrix is crucial for maintaining oversight of the requirements and ensuring that the system meets all specified needs.

💡Performance

Performance in the context of non-functional requirements refers to how well a system operates under certain conditions, such as response times and processing times. The video discusses the importance of defining performance requirements, such as how quickly a website should load or how fast a report should run, to ensure that the system meets user expectations and is considered usable.

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