CECILE G.

ESCALANTE
Defining Requirements

The Institute of Electrical and Electronics Engineers

(IEEE) provides the following definition:
• a condition or capability needed by a user to solve a problem or
achieve an objective;
• a condition or capability that must be met or possessed by a system
or system component to satisfy a contract, standard, specification, or
other formally imposed document;
• a documented representation of a condition or capability as in
definition (A) or (B).” (IEEE, (Std 610.12-1990))
Categories of Requirements

Functional requirements— Nonfunctional requirements—

Requirements for functions that the Requirements for constraints on the
system performs to directly execute system. These include constraints
the mission of the software. These about system performance,
include process steps, calculations, reliability, maintainability or ease of
data manipulations, or reporting use, cost, and other overall
activities. characteristics.
Nature of Requirements

The nature of requirements varies among methodologies. In some

methodologies, requirements are only the needs that business users
describe at the highest level of abstraction.

In others, the needs may be described at a greater level of detail, including

many specific design elements that are elements of system design, such as
screen design.
Ways of expressing requirements

TEXTUAL BUSINESS USE MODELS PROTOTYPES PROGRAM

STATEMENTS CASES CODE
 Textual statements
A series of textual statements has been long used as the principal means for
expressing requirements. These have the form of “The system shall …” (for
mandatory or obligatory requirements), or “The system should …” (for preferred
requirements).
Business use cases
A business use case is a step-by-step narrative of a single business user (“Actor”) interacting
with the system, where the narrative yields a valuable result. An example of a business use
case for an online banking system is “Prequalify a Loan Request.”
Business use cases help stakeholders better understand requirements within the context of an actor
interaction. In some cases, textual requirements statements are actually developed from the business
use case. The business use case in Table 6.2 may give rise to the following textual requirement:

• The system shall have the ability to prequalify an online Loan Request (business use case
“Prequalify a Loan Request,” basic course of action)

Another requirement is also evident from the business use case, but will only be complete when the
alternative path 2 is completed in it:

• The system shall have the ability to provide options to customers whose online Loan
Request fails to prequalify (business use case “Prequalify Loan Request,” alternative path 2
will determine the option in the event the loan request is not accepted online)
 Models
• a description or analogy used to help visualize something (as an atom) that cannot be
directly observed” (Merriam-Webster Online Dictionary “model”)
• is the cost-effective use of something in place of something else for some cognitive
purpose
• represents reality for the given purpose; the model is an abstraction of reality in the
sense that it cannot represent all aspects of reality
• are used to tease apart the “big ball of mud”
• represent different aspects of the real system (i.e., borrowing from the phrase in the
aforementioned definition, “aspects of reality”) so that each aspect may be addressed
individually, in a simplified manner.
 Sample Aspects that can be Modeled
Motivation - the “why” of the system, the rationale and motivation for the system and
requirements. The motivation may reflect the organization’s internal objectives, or those of
external organizations such as regulatory agencies. The Business Motivation Model (BMM) is a
model of the various considerations of motivation.

Organization - the people and roles that interact with the system.

Location - the physical locales of system hardware and software.

 Different Models in Requirements
• Business planning models (such as the BMM). These models represent strategic and
operational plans for the business and are important drivers for systems.
• Business process models (and other sequential activity models). These models depict the
required flow of activities that the system and the actors are to execute.
• Semantic models such as data, object, and fact models. These models contain the
glossary of terms, the fact types, and logical data structures that are required for an
accurate and shared set of semantics for the system.
• Organization and location models. These models contain the stakeholders and the
relevant physical locations of the system and stakeholders.
 Prototypes
Prototypes are a mock-up of the software solution that permits the business user
to visualize the software by displaying the user interface of the proposed solution.

The value of prototyping is that it provides the business user with a more tangible
idea of the software than even a model can provide.
 Program code
The Agilists’ goal is to deliver rapidly, based on what is known, and then to evolve quickly
based on what is learned from each iteration. So, requirements, evolve through iterative
deliverables. “The urge to write requirements documentation should be transformed into
an urge to instead collaborate closely with your stakeholders and then create working
software based on what they tell you” (Ambler, 2007a).

In other words, Agilists do not consider requirements to be an asset that is maintained in

addition to and separate from the working system. Models and business use cases serve
only as aids to shared understanding and guidance for developers and testers.
  Business Motivation Model (BMM)
- it is a model that support
Business logic business planning and
manage business motivations
in classical that drives projects and
related systems
functional - It captures courses of action
that implement strategy and
requirements related tactics, to achieve a
desired result driven by goals
and objectives.
Business logic in classical functional
requirements
 Business Process Model (BPM)
- the business process model and the Decision Model are connected via the decision
task (or business rule task) in the business process model
- This connection is best strengthened by using the same naming conventions for the
business decision and the decision task. Not shown is that the Decision Model and
the business process model share the following common metadata: Business Policy,
Business Objectives, and Business Tactics (which is also common to the BMM.)
- The connection between the business process model and the Decision Model is
extremely powerful in developing an agile business process. It also completes the
connections among the business process model, Decision Model, and BMM. These
connections create complete traceability from a single task in a business process
model to a business decision in the Decision Model to a directive in the BMM
 Business logic in classical functional
requirements
 Business Use Case (BUC)
- The connection between a business use case and the Decision Model occurs at
those use case steps identified as decision steps. In practice, the use of decision-
oriented words, such as determine, calculate, estimate, validate, and so on, are good
clues that a business decision exists behind the step.
- Once the decision steps in a business use case are identified, a Decision Model is
needed, if one is not already in existence. The use case step needs a unique
identifier for each business decision noted in it, the connection point between the
use case step and the Decision Model.
- Decision steps in a business use case are similar to decision tasks in a business
process model and become the connecting points between the business use case
and the Decision Model.
 Business logic in classical functional
requirements
 Semantic Models (SM)
- a semantic model is a representation of the pieces of information
referenced in a Decision Model, as conditions or conclusions.
- A range of semantic models are developed to serve as requirements
artifacts. They include the following:
a.Glossary of fact types - It is simply a list of the fact types used in the
Decision Model with corresponding business definitions and, often,
domain specifications.
- It is required to support a Decision Model so that the model can
be interpreted correctly.
Thank you!