1. Requirements Engineering Flashcards
What are software requirements?
Requirements are statements of what the proposed software must do in order to fulfill the user’s expectations.
Where are Software requirements used?
Gathered during the early stages of the SL process, but used during every stage of the process: Design, implementation, testing and deployment.
What do Software requirements describe?
What, not How
Describe features/characteristics and contstraints (What the software should or shouldn’t do), not implementation or design details
What are restraints?
Restraints are the minimum or maximum requirements (lower and upper bounds) for the system. Like the maximum file size, or the minimum speed of the system.
How much detail should requirements have?
Requirements must be as objective, clear, complete and precise as possible, without any amibguity. They should not be open subjective for interpretation.
Why are requirements so important?
Errors in requirements lead to errors in the software.
Types of requirements
Product vs Process
Functional vs Non-Functional
Emerging and Quantifiable
User, Software and System requirements
Product or process requirements
PRODUCT:
-The software being developed
PROCESS
- How the software will be developed
- Development techniques and methodologies
- Developer accreditation: Prince2, ISO 9001, CMMI, RUP etc.
Functional and Non-Functional requirements
Functional:
- Product Features
- User Requirements
Non-Functional
- Product Properties
- User Expectations
FUNCTIONAL:
Functional requirements define the basic system behaviour. Essentially, they are what the system does or must not do, and can be thought of in terms of how the system responds to inputs. Functional requirements usually define if/then behaviours and include calculations, data input, and business processes. Functional requirements are features that allow the system to function as it was intended. Put another way, if the functional requirements are not met, the system will not work. Functional requirements are product features and focus on user requirements.
NON-FUNCTIONAL
While functional requirements define what the system does or must not do, non-functional requirements specify how the system should do it. Non-functional requirements do not affect the basic functionality of the system (hence the name, non-functional requirements). Even if the non-functional requirements are not met, the system will still perform its basic purpose. If a system will still perform without meeting the non-functional requirements, why are they important? The answer is usability. Non-functional requirements define system behaviour, features, and general characteristics that affect the user experience. How well non-functional requirements are defined and executed determines how easy the system is to use, and is used to judge system performance. Non-functional requirements are product properties and focus on user expectations.
What are the different kinds of non-functional requirements
The Quality characteristics of software:
Performance. How fast does it need to operate?
Usability. This focuses on the appearance of the user interface and how people interact with it. What colour are the screens? How big are the buttons?
Maintainability: How often does it need to be updated
Security. What are the security requirements, both for the physical installation and from a cyber perspective?
Reliability / Availability. What are the uptime requirements? Does it need to function 24/7/365?
Scalability. As needs grow, can the system handle it? For physical installations, this includes spare hardware or space to install it in the future.
Supportability. Is support provided in-house or is remote accessibility for external resources required?
Sustainabillity: Carbon footprint. Defines how many resources an operation may or may not consume.
Power usage: Conserving mobile battery life
What are some functional requirements
Business requirements. This usually contains the ultimate goal, such as an order system, an online catalogue, or a physical product. It can also include things like approval workflows and authorization levels.
Administrative functions. These are the routine things the system will do, such as reporting.
User requirements. These are what the user of the system can do, such as place an order or browse the online catalogue.
System requirements. These are things like software and hardware specifications, system responses, or system actions.
Emergent properties
Some requirements represent emergent properties
of software—that is, requirements that cannot
be addressed by a single component but that
depend on how all the software components
interoperate. The throughput requirement for a
call center would, for example, depend on how
the telephone system, information system, and
the operators all interacted under actual operating
conditions. Emergent properties are crucially
dependent on the system architecture.
System and Software requirements
In this topic, “system” means:
an interacting combination of elements to accomplish a defined objective. These
include hardware, software, firmware, people, information, techniques, facilities, services, and other support elements, as defined by the International Council on Software
and Systems Engineering (INCOSE) [3].
there is a need to separate concerns by defining the boundaries between elements of a system, so that requirements can be specified for each element..
Quantifiable requirements
Requirements that can be attributed to a value, or compared to a range of values or a threshold.
Requirements that can be measured precisely.
Emphasis is on ombjective values that can be identified.
What are the 4 Activities of the requirements Process? (EASY)
Elicitation
Analysis
Specifications
Yes, it works (validation)
5 Major Process Actors
Users: This group comprises those who will
operate the software. It is often a heterogeneous
group involving people with different roles and requirements.
• Customers: This group comprises those who
have commissioned the software or who represent
the software’s target market.
• Market analysts: A mass-market product
will not have a commissioning customer, so
marketing people are often needed to establish
what the market needs and to act as
proxy customers.
• Regulators: Many application domains, such
as banking and public transport, are regulated.
Software in these domains must comply
with the requirements of the regulatory
authorities.
• Software engineers: These individuals have a legitimate interest in profiting from developing the software by, for example, reusing components in or from other products. If, in this scenario, a customer of a particular product has specific requirements that compromise the potential for component reuse, the software engineers must carefully weigh their own stake against those of the customer. Specific requirements, particularly constraints, may have major impact on project cost or delivery because they either
fit well or poorly with the skill set of the engineers. Important tradeoffs among such requirements should be identified.
What is the aim of requirements elicitation?
To determine the problem/s the proposed software will solve
Stages of Requirements elecitiation?
- Identify Stakeholders
- Identify the overall
purpose of the software - Define the Scope of software and any connections or other external software or systems
- identify the major features of the software
- The main user goals
- Establishing priority, in terms of which features are considered the most important, so as to be able to satisfy these first
What is project scope and why is it important to define the scope of a software project before requirements elicitation begins?
This involves providing a description of the software being specified and its purpose and prioritizing the deliverables to ensure the customer’s most important business needs are satisfied first. This minimizes the risk of requirements specialists spending time eliciting
requirements that are of low importance, or those that turn out to be no longer relevant when the software is delivered
Requirement Sources
Domain Knowledge: The software engineer
needs to acquire or have available knowledge
about the application domain. Domain
knowledge provides the background against
which all elicited requirements knowledge
must be set in order to understand it. It’s
a good practice to emulate an ontological
approach in the knowledge domain. Relations
between relevant concepts within the
application domain should be identified.
User Goals: The term “goal” (sometimes called
“business concern” or “critical success factor”)
refers to the overall, high-level objectives
of the software. Goals provide the motivation
for the software but are often vaguely
formulated. Software engineers need to pay
particular attention to assessing the value
(relative to priority) and cost of goals. A feasibility
study is a relatively low-cost way of
doing this.
Organizational Environment: The organizational environment. Software
is often required to support a business process,
the selection of which may be conditioned
by the structure, culture, and internal
politics of the organization. The software
engineer needs to be sensitive to these since,
in general, new software should not force
unplanned change on the business process.
Process Actors, Stakeholders: Much software has proved unsatisfactory
because it has stressed the requirements
of one group of stakeholders at the
expense of others. Hence, the delivered
software is difficult to use, or subverts the
cultural or political structures of the customer
organization. The software engineer
needs to identify, represent, and manage the viewpoints of many different types of stakeholders
Business Rules: These are statements that
define or constrain some aspect of the structure
or the behavior of the business itself. “A
student cannot register in next semester’s
courses if there remain some unpaid tuition
fees” would be an example of a business rule
that would be a requirement source for a university’s
course-registration software.
Operational Environment: Requirements
will be derived from the environment in
which the software will be executed. These
may be, for example, timing constraints
in real-time software or performance constraints
in a business environment. These
must be sought out actively because they can
greatly affect software feasibility and cost as
well as restrict design choices.
Common Elicitation Techniques
- Interview
- Facillitated Discussions
- Scenarios/use case
- Observational study
- User Stories: “As a , I
want so that .” - Prototypes
What is the aim of requirements analysis?
To determine if sufficient information has been gathered.
To facilitate understanding of the features and bounds of the proposed software system.
Develop conceptural models to aid understanding of the client’s problem, the software and it’s operational environment
Steps in the requirements analysis process?
- Requirements classification
- conceptual modeling
- Architecture design and requirements allocation
- Requirements negotiation
- Formal analysis
- Fault tree anayslysis
- Risk assessment
What is requirements classification?
Sort and group related requirments according to type eg. ) function and non functional, product and process etc.
What is conceptual modeling?
models that facilitate understanding of the problem the software is being developed to address, the organisational and operational context in which the softwre will operate, and the relationship between the software’s requirements.
What is architectural design and requirements allocation?
The process of identifying possible software componenents.
The process of identifying and then assigning architectural components to satisfy requirements is known as requirements allocation.
What is requirements negotiation?
To address conflicting requirements. May require conflict resolution.
What is formal analysis?
A way of modeling systems, that uses formal mathematical notations which lends itself to formal mathematical proofs
Usually applied to safety critical or high integrity systems.
What is fault tree analysis?
A way of understanding potential system failures and their contributing factors
How to perform a fault tree analysis?
- identify the udnesired outcome - the top event
- Work bacwards, identifying causal factors that contribute to the top event occuring.
- Recurse through each of these factors, identifying further causal events. Repeat until no more factors left.
- Design elements that intervene or prevent a fault or contributory factors, can now be specified in the system.
What is the aim of requirements specification?
To develop the specification document, called a “software requirements specification” document or SRS
What specification documents are needed for larger systems?
System definition Document
System Requirements Specification
Software Requirements Specification
What is the system definition document?
describes the overall system, including software and non-software components. This document aims to provide a list of high-level features and responsibilities that the system should provide or undertake.
Expressed in domain-centric terms, not developer terms.
Audience includes all interested parties. -clients, users, developers, etc
