Software Functional and Non-Functional Requirements

Functional Requirements

• Functional requirements detail what a software should do, focusing on its functions.
• Examples include saving a file, printing, or making a backup.
• Understanding the client's requirements through communication is essential for correct software development.
• Software requirements can often be complicated and subject to change.

Non-Functional Requirements

• Non-functional requirements describe the characteristics a software should have.
• Examples are speed, security, or reliability.
• Need more information before the characteristics can can be proper requirments

Approaches to Requirements

• Software Requirements Specification (SRS) is a document that lists all functional and non-functional requirements.
• The SRS may form a legal contract between the client and the developers.
• Agile methods encourage client involvement, incremental software development, and iterative requirement determination.

Requirements Principles

• Concentrate on what the software should do, not how it should do it.
• Projects always start with uncertainty, which must be reduced.
• Breaking down requirements into smaller pieces aids understanding.

Software Requirements Specification (SRS)

• With an SRS, all or most requirements are specified up-front
• It resembles a traditional engineering project.
• Negotiation with the client establishes the scope and price.
• "Scope" refers to "how much we're talking about”.
• "Scope" refers to how much you're going to deliver.
• Then the software is designed and built.
• An SRS must be unambiguous, consistent, complete and concise.
• This is to avoid confusing developers.

SRS Layout

• An SRS typically contains sections such as:
  • Introduction
  • Overall description
  • External interface requirements
  • Functional requirements
  • Non-functional requirements

Changing Requirements

• Requirements usually change due to the initial difficulty in getting details right.
• Tradeoffs such as cost vs. performance, complex software environments, different users, and interactions with other systems contribute to changes.
• Software is written because the the clients needs have never been met before

Changing Requirements in Traditional Software Engineering (SE)

• Faulty requirements are expensive to fix late in projects.
• It could also mean redoing a lot of work.
• If the requirements are going to change, the sooner the better.
• "Inspection" is used to ensure quality.
• Inspection a formal process for reviewing the SRS, and anything else we produce.

Agile Development

• Takes a different approach to requirements.
• The entire project is completed through series of short bursts of development.
• Each short burst is called an "iteration" or "sprint".
• Software and requirments are built up incrementally.
• Rapid, incremental delivery ensures faulty requirements are found nearly immediately.
• Damage is limited to one iteration's worth of work.
• Scope and price are determined for each iteration, not the entire project.
• Includes methods (Scrum, eXtreme Programming, Crystal, etc.).
• Iterations last 1 to 4 weeks.

Agile Iterations

• Subsequent iterations involve agreeing with the client on additional requirements and updating the product.

Prototyping

• Involves building a dummy version of the software quickly to try out an idea or set of ideas.
• Prototypes are used to resolve uncertainty and improve requirements.
• Prototypes often comprise the user interface.
• The client can easily critique a prototype.

User Stories

• Agile methods often use user stories, which are snippets of text with three parts (user role, ability, benefit).
• Example phrasing:
  • "As a [user role], I want to [ability] so that [benefit]."
  • "In order to [benefit] as a [user role], I want to [ability]."
• User stories are created with the client and form the basis of the next iteration.
• The focus on breaking down requirements and resolving uncertainty.
• User stories makes it obvious what features the software needs, and who needs them.

User Stories: Common Sense

• User stories are about users—the people who will actually use the software.
• User stories are not about the developers or non-people.
• Ability is what the software should do.
• Benefit is why to care about the ability.

Backlogs

• Agile methods use a backlog of user stories, similar to a work breakdown structure, but backlogs evolve and change.
• User stories are added to the backlog throughout the project, and removed when finished.
• The work is carried out story-by-story, starting with the highest priority user stories.

Stakeholders

• The "who" question is important.
• Need to know, who cares about the software, and who is affected by it
• Stakeholders include users, developers, clients and other indirectly affected parties.

Actors

• Some stakeholders are actors (interact with the system, but are not part of the system).
• Can be human (administrators, managers, etc.) or non-human (databases, sensors, robots, etc.).

Databases

• Databases are pieces of software used for storing data for use cases.
• Databases stores large amounts of complex, structured data.
• The system must communicate with the database to store and retrieve, however the database isn't part of the system.

Databases: What You Need to Know

• Databases store, delete, and retrieve data when asked.
• Databases don't make decisions or take actions.
• Databases communicate with other software.

Some External Systems are Irrelevant

• A lot of what we do in the system is irrelevant.
• External systems that can be ignored as they are low level include operating system, input/output and networking infrastructure.
• Concentrate on "what", not "how".
• Human actors use input output.
• OS and networking is done by non-human actors.

Use Cases

• Describe how a software system interacts with the outside world.
• Multiple use cases exist for any given software system.
• Each use case describes a functional requirement.
• Parts of functional requirements, or several functional requirements can be explained using use cases.

Parts of a Use Case

• Header: Basic information (what it's for, who's involved, when it happens).
• Flow of Events (FoE): Numbered steps that describe the system's interaction with actors and what should normally happen.
• Extensions: Alternative scenarios describing what happens when things go wrong or differently.

Example use case

• Video sharing website (like YouTube)
• Use cases:
  • Watching a video
  • Uploading a video
  • Posting a comment on a video
  • Reporting a video

Use Case Header

• Includes the use case's goal, primary actor, secondary actors, preconditions, and trigger (event to start the use case).

Actors and Goals

• Each use case has one primary actor such as a person who initiates the system.
• If rarely the system itself is the primary actor.
• A secondary actor can be any other people or external systems involved.
• All use cases can have different actors.

Triggers and Preconditions

• Trigger an event that starts the use case's flow of events (FoE).
• There may or may not be a user action.
• Could (alternatively) be a time-of-day.
• Preconditions if false, will prevent the use case from starting.
• Preconditions can be when the user must be logged on.
• User must have permission to do X.

Scope

• Only concerned with the operation of the software system.
• An "in-scope" precondition is when the system can verify it.

Flow of Events

• Includes the uploader choosing a file, the system receiving it, the system converting the video, and storing video details.

A Closer Look at the Flow-of-Events (FoE)

• Contains a rough guide of 3–10 steps.
• The flow of events can include actions initiated by actor or system.
• Sometimes the significant processing is done by the system.
• Databases never initiate an interaction.

Flow-of-Events – Things to Avoid

• Should not show interactions between actors.
• This excludes technology related jargon.
• To prevent ambiguity, use active voice.
• States explicitly who or what carries out each action.

Extensions

• The main flow of events is referred to as the "happy days" scenario (everything goes right).
• Variations to this main scenario are extensions.

Parts of an Extension

• An ID is like "4B." This identifies two things.
• The step in the FoE that something might go wrong (or differently).
• Distinguishes one extension from another, if they occur at the same point.
• A condition states why the extension takes place.
• A list of steps – an alternate “mini” flow-of-events.
• An exit point tells what happens afterwards

Extensions – Things to Avoid

• Avoid overly-generic problems. e.g., database problems.
• Do not include the system cannot address.

What About "IF" Statements?

• These should not be used instead of extensions.

Design Scope and Goal Level (advanced)

• Use cases also have "design scope" and "goal level”.
• "Design scope" specifies what thing are you talking about, while "goal level" states how much functionality you are talking about.
• Scopes help break down large problems and simplify them.

UML Use Case Diagrams

• A diagram that shows:
  • The names of all Use cases
  • All the Actors
  • The relationships between them all.
• Actors are stick figures.
• Use cases are elipses.
• Do not show preconditions, triggers, or flow of events/extentions.

Diagrams

• Helps visualise the viewer and database and the 3 use cases.
• Includes the viewer and database actors, the database is involved in all use cases.

Who Does What

• User case diagrams should clearly show which actors participate in which use case.

The «include» Relationship

• Some use cases overlap with each other.
• One can include another.
• The inlcuded use case can be part of a larger use case.
• "Comment on Video” and “Report Video” can be done.
• Can be done separately or as part of "Watch Video”.

Actor Generalization

• Some actors can do everything that others actors can do, plus more.

Use Cases vs User Case Diagrams

• Limited usefulness.
• Diagrams are for display only.
• Fully-written use cases contain most of the information.

Use Case Diagrams are Not Flow Charts

• This is because it only shows which use case diagrams are related, and there are no arrows to indicate the process flow.