Requirement Definition and Classification

A requirement is referred to as the capability, attribute or condition that must be satisfied by

the demand or any form of challenge to ensure that a solution generated is able to
meet the needs of all those that are affected and or/ stakeholders.
Requirements may be known to constitute some notions such as:
• Business Drivers,
• Policies ,
• Business Rules,
• Business specifications which have a much more restrictive view for example, a
number of requirement methods like Use Case, is centric to articulate
requirements at a business level while others augment the Use Cases with
detailed functional requirements required by the developers.
For requirements to satisfy system design needs as a phase in software development
activity, the identification and selection of the same requirements is a key ingredient in
determining the reliability of the designed system to meet the user needs and the business
goals.
Therefore, requirement discovery important as the process of identifying and selecting
requirements using scientific techniques and or / methods with a purpose of generating an
appropriate solution to fix operational challenges affecting business process / activities.
Besides these criteria for individual requirements, three others apply to the set of requirements
and they include:
- Consistent
- Non redundant and
- Complete

Characteristics of requirements
These can be defined as attributes that are used to determine and or / define system
development. These attributes are descriptions that are significant in defining the quality of the
system for development, otherwise poor requirement definition will cause flaws in the quality
(performance) of the software and later lead to system re-design which calls for additional cost
for the organisation.
Therefore these characteristics include:
 Characteristics of Requirements
To be effective a set of Requirements must be complete and fully record the stakeholders' needs consistently, cohesively and
unambiguously.
Characteristics Notes
Atomic A requirement should be able to articulate a single stakeholder need or a quality attribute.
When a requirement contains multiple needs it is not possible to analyze the needs
independently.
Attainable The need specified in the requirement must be achievable. If a requirement is not attainable
the system will not be able to deliver the business value required by the stakeholders. identify
those requirements that are not traced to a lower level element.
Cohesive The requirements as a set must be consistent and cohesive and express the behavior of the
system; any gaps must be determined and overlap between requirements must be resolved.
Complete Each requirement must fully describe the necessary functionality or behavior of the system
that will result into satisfying the needs of the stakeholder.
Current A Requirement must be up-to-date and reflect the current knowledge and project status.
Enterprise Architect can assist the analyst by allowing the sources of requirements to be
modeled and the requirements themselves can be traced back to these artifacts so when the
source is changed all the affected elements could be located.
Unambiguous A requirement should be interpreted in only one way. Requirements that are ambiguous / not
clear lead to project delay, over budget or having the wrong functionality or behavior.
Cont… of characteristics
Characteristics Notes
Independent The requirements should be independent of each other, and not have overlapping statements
that conflict with each other or restate the same need. A degree of analysis will be required as
there will inevitably be some overlap, but this can be kept to a minimum by creating
requirements in hierarchies and working systematically.
Modifiable This means that a requirement can be changed without affecting other related requirements
including those which also apply to a Software (System) specification and requires that it can
be changed easily. The requirements themselves can easily be located through the search
facility, and the text and properties changed easily.
Traceable A requirement is a specification of a characteristic or behavior, and does not exist in isolation
but is typically related to up-process entities such as stakeholders, business drivers and goals,
and down-process entities such as Use Cases and components. Enterprise Architect allows
elements to be traced in any direction and provides a number of powerful tools to visualize the
traces, including the Relationship Matrix, the Traceability Window and the Requirements
diagram itself. The Insert Related Elements facility can be used to automatically construct a
diagram of traces.
Verifiable A requirement is verifiable if the implemented system or product can be tested to ascertain
that the requirement has been met by knowing the test that must be run to verify a particular
requirement. This can be achieved by using a system enables verification i.e. Enterprise
Architecture
Cont… of characteristics

Characteristics Notes
Necessary Requirements should record a capability or behavior that is really needed or that specifies that the
system or product should comply with constraints such as standards. Enterprise Architect enables
analysis can assist by allowing the modeler to relate each requirement back to its source,
requirements that have no source will be obviously identified as unnecessary or require further
investigation.
Feasible A requirement that cannot be implemented will mean that the need of the stakeholder will not be
met. It is best to identify these requirements as quickly as possible so as not to disappoint the
owner of the requirement. Through system enables analysis, analysts, architects, designers and
developers can discuss the requirements and determine their feasibility.
Understandable Requirements should be grammatically correct and written in a consistent style. Standard
conventions should be used. The word “shall” should be used instead of “will,” “must,” or “may.”
Implementation- Requirements should not contain unnecessary design and implementation information:
free (Abstract) e.g. Content information shall be stored in a text file.
How the information is stored is transparent to the user and should be the designer’s or architect’s
decision
ACTIVITY 2
System analysis as a pre-requisite activity to inform requirement analysis and system development phase
within a business environment, is usually by the System Analysts and System architects respectively. This
work is always supported by system enabled analysis as a technological tool also known as Enterprise
Architect.
i)Suggest what the comprehension is about.
ii)In your own view as a matter of roles, specify the functions the two human resources motioned in the
comprehension above.
iii)Requirements Engineering exercise has been automated using “Enterprise Architect”
Technology and simplifies the work of the systems analyst. Read about this tool and try compare the
degrees of efficiency in determining the characteristics of requirement as comparable to effort systems
analyst would take to generate requirements for a particular system to be developed to manage
operational challenges in an organisation.
iv) Use this method to determine the duties of a system analyst.

Source: http://www.informit.com/store/
Mastering the Requirements Process: Getting Requirements Right, 3rd Edition-97803218515743?
Copy the link and paste in the address of the browser
 Levels and Types of Requirements
Requirements are categorized into three main levels in which each sequentially fits into
another to cause an effect in the performance of the system – Users – Organisation
At this level we can look at:
System as the technology or software that the organisation operationalize to handle business
challenges users as clients or customers face when handling business transactions that define
the organisations functions.
•Business Requirements.
Business Requirements are high-level requirements that express the objectives and
desired outcomes of an organization.

They are typically defined in a business case or other statements by the product owner
or sponsor, the marketing department or the customer.

They attempt to explain why the organization is spending money and resources on the
project.
Business Requirements are high-level requirements that express the objectives and
desired outcomes of an organization.
High Level Requirements are mandatory requirements that describe a set of capabilities which a
project under consideration must achieve. Essentially, they define the expected outcomes, effects
or services to be delivered by the project (what employers want the project to deliver).
e.g. - reducing costs
- time saving (effective)
- handling multiple customers / clients in single unit time
In simple terms

Business Level:
Defines the business problems or opportunities about the product. Business requirements define
why the software product is being developed. They are the objectives of the customer requesting
the development of the software.
• Business requirements can be looked at in terms of what the business wants to achieve as directed by the owner’s
philosophy, vision mission and objectives
However to achieve that
Its important that you give high considerations to the
users / stake holders
- Directors of the business
- Funders
- Customers as key stake holder
- Internal Users (managers, employees)

System / Technology / Software/ Application

Thus, user need a high-level statement of the requirements, while system developers need a more detailed system
specification.
So, user and system requirements just refer to different levels of detail.
 Requirements Classification

High - Level
The reasons for the organization’s existence/ why
the business exists
Business
Requirements
The general intentions to be achieved as
User Customer needs, Specific measureable tasks
Requirements that cause the goal

Systems Functional and Non-Functional

Requirements

Detailed
Transitional Additional requirement / data conversion
Requirements or staff training actions
How to generate requirement of each level of three
categories:
• Business, Link video
• user and
• software requirements.
A Business Requirements Document (BRD) is a formal description of business-related objectives and expectations
an organization has regarding a specific project or business solution.
It commonly explains reasons to start a project, the set of business values it is expected to provide, and
the purpose behind doing the project, etc. The main idea of a BRD is to clarify all the business aspects of a project.

Why business requirements documents are important

While the advantages of writing a business requirements document may seem to be obvious, the most
significant ones:
• It provides reasons for initiating a project,
• reduce the chance of project failure due to misinterpreted requirements,
• connects a project to needed business goals,
• minimize rework and costs associated with it,
• create a clear roadmap of project development and monitoring,
• improve communication between different stakeholders, and much more.
When writing a BRD, its important that you associate your documentation with the
following areas od concern.
The SWOT analysis syndrome

The SWOT analysis:

S --- Strength

W --- Weaknesses

O ---- Opportunities

T -----Threats
It is good practice to ideally
differentiate between SWOT
analysis and Case Analysis
 The link between Business level and User level
The functions and or processes of the business (organisation) are indentedly executed by the specialized human
resources that are endowed in the respective faculties or departments. The personnel therefore is charged with the
responsibility of carrying out the transactions and routines that define the purpose for which the business was made.
Therefore it is imperative to establish the relationship between the actual business as an entity and the users of the
business as another entity. This is described in the functions and or roles each person plays in the business, whose
requirements must be established for successful prediction of the expected output.
Functional Requirements
• Functional requirements are requirements which concentrate on what the system / Software / Technology can
do to meet the business and User requirements.
• These are statements of services the system should provide, how it react to particular inputs and
how it behaves in particular situations.
• Functional Requirements (FR) bridge the business and the inherent teams to give a service which provides a
good definition of what the system/software/Technology must do for its users that will in turn meet the business
goals.
• Functional Requirements can be described using Use Cases or User Stories and detailed textual
Requirements that describe what the architect must design and the developer must implement.
Examples of Use Case

A Use Case is seen to be expressed in the Actor and Scenario Method

Actor is expressed as the Initiator / Trigger of a scenario in which the scenarios is the real Use Case
that is expressed as the process . In this case, the process is the Use Case.
This approach is trending approaches that are used in system modeling using a known modeling
language, e.g. UML

Submit
requirement

System Analyst
 Functional Requirement cont…..
• A Functional Requirement (FR) is also termed as a description of the service that the software must offer. It describes a
software system or its component.
A function is nothing but inputs to the software system, its behavior, and outputs. It can be a calculation, data manipulation,
business process, user interaction, or any other specific functionality which defines what function a system is likely to
perform. Functional Requirements in Software Engineering are also called Functional Specification.
• In software engineering and systems engineering, a Functional Requirement can range from the high-level abstract
statement of the sender’s necessity to detailed mathematical functional requirement specifications. Functional software
requirements help you to capture the intended behaviour of the system.
Examples of functional requirements includes:
• Business Rules.
• Transaction corrections, adjustments, and cancellations.
• Administrative functions.
• Authentication.
• Authorization levels.
• Audit Tracking.
• External Interfaces.
• Certification Requirements.
Examples cont………………………
• Output reports to be provided.
• Ability and easy of interfacing with external users.
• Ability of make corrections, updates to inputted data.
• Regulatory requirements (also potential non-functional requirements).

Pros/advantages of creating a typical functional requirement document

• Helps you to check whether the application is providing all the functionalities that were mentioned in the
functional requirement of that application
• A functional requirement document helps you to define the functionality of a system or one of its subsystems.
• Functional requirements along with requirement analysis help identify missing requirements. They help clearly
define the expected system service and behavior.
• Errors caught in the Functional requirement gathering stage are the cheapest to fix.
• Support user goals, tasks, or activities

.
User Level:
User level defines functionality of the software product from the user’s perspective. They define what
the software has to do in order for the users to accomplish their objectives.
At this level, User requirements, also referred to as stakeholder requirements, are conceived as statements
that describe what value individual user groups (customers, managers, etc.) expect of a certain solution to
deliver. These statements are often seen as a bridge between the broad-based business requirements and specific
system requirements.

Stakeholder / User Requirements

These are statements of the stakeholders that express their needs and expectations and
describe the features that must be met if the business requirements are to be fulfilled.
Analysts tend to focus on the functional aspects of the needs but stakeholders' expectations which
include performance and reliability variety of other non- functional needs. Both are critical and act as
precursors to the definition of the functional and non functional requirements that will be consumed by
the designers and implementers to create solutions that meet the customer's expectations.
User requirement specification (URS)
• The User Requirements Specification describes the business needs for what users require from the system. User
Requirements Specifications are written early in the validation process, typically before the system is created.
• They are written by the system owner and end-users, with input from Quality Assurance. Requirements specified in the
URS are usually tested in order to qualify system performance and reliability so as to guarantee User Acceptance
Testing (UAT).
• User Requirements Specifications are not technical in nature readers will understand it using general knowledge of the
system in order to understand the requirements outlined in the URS.
User requirements are defined using natural language, tables and diagrams as these can be understood by all users.

Problems with natural language

•Lack of clarity: Precision is difficult without making the document difficult to read. Functional and non-functional
requirements tend to be mixed-up.

•Requirements amalgamation: Several different requirements may be expressed together.

System Requirements
(Software / Technology Requirements)
System requirements
These are structured descriptions setting out details of the system’s functions, services and operational constraints.
They defines what should be implemented / intended to be a basis for designing the system so may be part of a
contract between client and contractor.

Non-Functional Requirements
These are quality attributes which describe how well a system will perform when it is operating.

These typically define properties and constraints on how the system should be behave as a whole and include
attributes such:
• performance,
• security,
• fault development and tolerance.
• reliability,
• response time and storage requirements,
• I/O device capability
 • system representations,
• process requirements may also be specified mandating a particular CASE system,
• programming language or development method.
• Performance,
• scalability,
• portability,
• compatibility,
• reliability,
• availability,
• maintainability,
• Data Integrity
• Security,
• localization, and
• usability.
Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless.
• Performance and scalability.
How fast does the system return results? How much will this performance change with higher
workloads?
• Portability and compatibility.
Which hardware, operating systems, and browsers, along with their versions does the software run on?
Does it conflict with other applications and processes within these environments?
• Reliability, maintainability, availability.
How often does the system experience critical failures? How much time does it take to fix the issue
when it arises? And how is user availability time compared to downtime?
Usually, some non-functional requirements may be grouped with others since the approaches to
documenting these requirements overlap and some can’t be estimated without the other ones.

• Security. How well are the system and its data protected against attacks?

• Usability. How easy is it for a customer to use the system?

• Localization
Is the system compatible with local specifics? The localization attribute defines how well a system or
its element falls in line with the context of the local market-to-be. The context includes local
languages, laws, currencies, cultures, spellings, and other aspects. The more a product sticks with it,
the more success it should have with a particular target audience.
Comparisons between Functional and Non-Functional Recquirements
Summary of Non-functional requirement types
Non-functional
requirements

Product Organisational External

requirements requirements requirements

Efficiency Reliability Portability Interoperability Ethical

requirements requirements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requirements requirements requirements

Performance Space Privacy Safety

requirements requirements requirements requirements