Page |1

Information Gathering: Interactive Methods

SUMMARY:

Stakeholders- the Source of System Requirements

The primary source of information for functional system requirements is from the various
stakeholders of the new system.

Stakeholders are all the people who have an interest in the successful implementation of the
system.

Generally, stakeholders are categorized into three groups: users, clients and technical
staff.

User stakeholders
 User stakeholders are those who actually use the system in a daily basis. User roles –
that is, types of system users – should be identified in two
dimensions: horizontally and vertically.

Horizontal user roles. The analyst must look for the information flow across departments or
functions (i.e. Inventory system may affect different department like receiving, warehousing,
sales and manufacturing).

Vertical user roles. The analyst must look for the information needs of clerical staff, middle
management and of senior executives. Generally, vertical user roles include:
1. Business operations users. These are the people who use the system to perform the
day-to-day operations of an organization. These operations are called transactions – a
piece of work done in an organization such as “enter an order”.
2. Query users. A person who needs current information from the system. This person
may be the same person as to the business operations user or someone else. A query is a
request for information.
3. Management users. These are people who are responsible for seeing that the company
is performing its daily procedures efficiently and effectively. They need statistics and
summary information from a system.
4. Executive users. A person interested in strategic issues, as well as the daily
issues. They typically want information from the system so that they can compare overall
improvements in resource utilization.

Client stakeholders
A client stakeholder is a person or group who is providing the funding for the project.
- In many cases, the client is the same group as the executive users. However, the
clients may also be a separate group or people, such as a board of
trustees or executives in a parent company.
 Page |2

- The client or a direct representative on a steering or oversight committee also usually

maintains ongoing approval and release of funds.

Technical stakeholders
- The technical staffs are the people who ensure that the system operates in the
computing environment of the organization.
- It is the source of technical requirements.
- These people provide guidance in such areas as programming language, computer
platforms, and other equipment.

REFLECTION:
With this lesson, it is important that your stakeholders are the ones whom the system
development depends. With what the stakeholders want to happen and think, it is then that
the system would be able to function on its desired functions.

Validating the Requirements

 Page |3

SUMMARY:
Validation - to establish the fitness or worth of a software product for its operational mission.
Verification - to establish the truth of the correspondence between a software product and its
specification.
The four basic V&V criteria for requirements and design specifications are:
1. Completeness
2. Consistency
3. Feasibility
4. Testability
Completeness:
A specification is complete to the extent that all of its parts are present and each part is fully
developed. There are several properties which a software specification must exhibit in order
to assure its completeness.

Consistency:
A specification is consistent to the extent that its provisions do not conflict with each other or
with governing specifications and objectives.

Feasibility:
A specification is feasible to the extent that the life-cycle benefits of the system specified will
exceed the life-cycle costs. Thus, feasibility involves more than verifying that a system can be
developed which satisfies the functional and performance requirements. It also implies
validating that the specified system will be sufficiently maintainable, reliable, and well human-
engineered to keep the system's life-cycle balance sheet positive.
Further, and most importantly, it implies the identification and resolution of any high-risk
issues involved, before the commitment of large numbers of people to detailed development.

Testability:
A specification is testable to the extent that one can identify an economically feasible
technique for determining whether or not the developed software will satisfy the specification.
In order to be testable, specifications must be specific, unambiguous, and quantitative
wherever possible. .

RELIABILITY AND AVAILABILITY CHECKLIST

• Reliable Input Handling.
• Reliable Execution
• Error Messages and Diagnostics
• Backup & Recovery

REFLECTION:
It is best to know the worth of the system being developed on how it would affect if it
would be fully functional and knowing that you have made it right.
 Page |4

Modeling System Requirements: Use Cases

SUMMARY:
 Page |5

• One of the primary challenges is the ability to elicit the correct and necessary system
requirements from the stakeholders and specify them in a manner understandable to them
so those requirements can be verified and validated.
User-centered development – a process of systems development based on understanding
the needs of the stakeholders and the reasons why the system should be developed.

Use-case modeling – the process of modeling a system’s functions in terms of business

events, who initiated the events, and how the system responds to those events.
• Use-case modeling has roots in object-oriented modeling.
• Gaining popularity in non-object development environments because of its
usefulness in communicating with users.
• Compliments traditional modeling tools.

Benefits of Use-Case Modeling

• Provides tool for capturing functional requirements.
• Assists in decomposing system into manageable pieces.
• Provides means of communicating with users/stakeholders concerning system
functionality in language they understand.
• Provides means of identifying, assigning, tracking, controlling, and managing system
development activities.
• Provides aid in estimating project scope, effort, and schedule.
• Aids in defining test plans and test cases.
• Provides baseline for user documentation.
• Provides tool for requirements traceability.
• Provides starting point for identification of data objects or entities.
• Provides specifications for designing user and system interfaces.
• Provides means of defining database access requirements.
• Provides framework for driving the system development project.

System Concepts for Use-Case Modeling

Use case – a behaviorally related sequence of steps (scenario), both automated and manual,
for the purpose of completing a single business task.
• Description of system functions from the perspective of external users in
terminology they understand.
Use-case diagram – a diagram that depicts the interactions between the system and external
systems and users.
• Graphically describes who will use the system and in what ways the user
expects to interact with the system.
Use-case narrative – a textual description of the business event and how the user will
interact with the system to accomplish the task.

Basic Use-Case Symbol

Use case – subset of the overall system functionality
 Page |6

• Represented by a horizontal ellipse with name

of use case above, below, or inside the ellipse.

Actor – anyone or anything that needs to interact with the system to exchange information.
• human, organization, another information system,
external device, even time.
Temporal event – a system event triggered by time.
• The actor is time.

TYPES OF ACTORS
• Primary business actor
• The stakeholder that primarily benefits from the execution of the use case.
• e.g. the employee receiving the paycheck
• Primary system actor
• The stakeholder that directly interfaces with the system to initiate or trigger the
business or system event.
• e.g. the bank teller entering deposit information
• External server actor
• The stakeholder that responds to a request from the use case.
• e.g. the credit bureau authorizing a credit card charge
• External receiver actor
• The stakeholder that is not the primary actor but receives something of value
from the use case.
• e.g. the warehouse receiving a packing slip

REFLECTION:
With this chapter, I learned that Use Case Diagram Provides tool for capturing
functional requirements in order for the system developers and system owners to analyze the
functions and flow of the system with the Use Cases.

The Entity-Relationship Model

SUMMARY:

 Requirements Analysis: Understand what data will be stored in the database, and the
operations it will be subject to.
 Conceptual Design: (ER Model is used at this stage.)
 Page |7

 What are the entities and relationships in the enterprise?

 What information about these entities and relationships should we store in the database?
 What are the integrity constraints or business rules that hold?
 A database `schema’ in the ER Model can be represented pictorially (ER diagrams).
 Can map an ER diagram into a relational schema.
 Logical Design: Convert the conceptual database design into the data model underlying
the DBMS chosen for the application.
 Schema Refinement: (Normalization) Check relational schema for redundancies and
anomalies.
 Physical Database Design and Tuning: Consider typical workloads and further
refinement of the database design (v.g. build indices).
 Application and Security Design: Consider aspects of the application beyond data.
Methodologies like UML often used for addressing the complete software development cycle.

ER Model Basics
 Entity: Real-world object distinguishable from other objects. An entity is described
using a set of attributes.
 Entity Set: A collection of entities of the same kind. E.g., all employees.
 All entities in an entity set have the same set of attributes.
 Each entity set has a key(a set of attributes uniquely identifying an entity).
 Each attribute has a domain.
 Relationship: Association among two or more entities. E.g., Peter works in Pharmacy
department.
 Relationship Set: Collection of similar relationships.
 An n-ary relationship set R relates n entity sets E1 ... En; each relationship in R
involves entities e1  E1, ..., en  En
 Same entity set could participate in different relationship sets, or in different
“roles” in same set.
 Relationship sets can also have descriptive attributes (e.g., the since attribute of
Works_In). A relationship is uniquely identified by participating entities without
reference to descriptive attributes.

Key Constraints (a.k.a. Cardinality)

 Consider Works_In An employee can work in many departments; a dept can have
many employees.
 In contrast, each dept has at most one manager, according to the key constraint on
Manages.

Weak Entities
 A weak entity can be identified uniquely only by considering the primary key of another
(owner) entity.
 Owner entity set and weak entity set must participate in a one-to-many
relationship set (one owner, many weak entities).
 Weak entity sets must have total participation in this identifying relationship set.
 transac# is a discriminator within a group of transactions in an ATM.
 Page |8

 Conceptual design follows requirements analysis,

 Yields a high-level description of data to be stored
 ER model popular for conceptual design
 Constructs are expressive, close to the way people think about their
applications.
 Basic constructs: entities, relationships, and attributes (of entities and relationships).
 Some additional constructs: weak entities, ISA hierarchies, and aggregation.
 Note: There are many variations on ER model.
 Several kinds of integrity constraints can be expressed in the ER model: key
constraints, participation constraints, and overlap/covering constraints for ISA
hierarchies. Some foreign key constraints are also implicit in the definition of a
relationship set.
 Some constraints (notably, functional dependencies) cannot be expressed in the
ER model.
 Constraints play an important role in determining the best database design for
an enterprise.
 ER design is subjective. There are often many ways to model a given scenario!
Analyzing alternatives can be tricky, especially for a large enterprise. Common
choices include:
 Entity vs. attribute, entity vs. relationship, binary or n-ary relationship, whether or
not to use ISA hierarchies, and whether or not to use aggregation.
 Ensuring good database design: resulting relational schema should be analyzed and
refined further. FD information and normalization techniques are especially useful.

REFLECTION:
I learned from this lesson that relationship will determine the design of the data storing
in the database. I understand that through data relationship, it would determine the function of
each data to the other.

The Object-Oriented Approach to Requirements

SUMMARY:

The Unified Modeling Language and the Object Management Group

- Object-oriented modeling notation is Unified Modeling Language (UML)
- UML was presented to Object Management Group (OMG) as standard modeling
technique
- Purpose of Object Management Group
 Page |9

 Promote theory and practice of object technology for development of distributed

systems
 Provide common architectural framework for OO

Object-oriented approach has complete set of diagrams that together document the
user’s need and define system requirements
Requirements specified using following models:
 Domain model class diagrams
 Use case diagrams
 Use case detailed model, either descriptive format or activity diagram
 System sequence diagrams (SSDs)

Object-Oriented Requirements
- Systems development process starts with identification of events and things
 Events are business processes that new system must address
 Things are problem domain objects involved in business process

Object-Oriented Approach Models

 Class diagram – definition of system components
 Use case diagrams and use case descriptions – show user roles and how they use the
system
 Systems sequence diagrams (SSDs) – define inputs and outputs and sequence of
interactions between user and system for a use case
 State chart diagrams – describe states of each object
 Activity diagrams – describe user activities

Use Case Diagram

- Graphical models that summarize information about actors and use cases
- System developer
 Looks at system as whole
 Identifies major uses from event table
 Identifies functions to be supported by new system
 Organizes use cases

CRUD analysis
 CRUD – Create, Read/Report, Update, Delete
 Information Engineering (IE) technique to identify event table events or develop use
case diagram
 Compares identified use cases with domain model class diagram
 Every class in class diagram must have use cases to support creating, reading,
reporting, updating, and deleting object instances
 Confirms system integration requirements
 P a g e | 10

Identifying Inputs and Outputs – The System Sequence Diagram

- Collaboration diagram
 Emphasizes objects that interact together to support a use case diagram
 May be used alone or with sequence diagram
- System sequence diagram
 Shows sequence of interactions between objects and flow of events in a single
use case
 Focuses on message details
 Used more frequently in industry

SSD Notation
 Actor represented by stick figure – person (or role) that “interacts” with system by
entering input data and receiving output data
 Object notation is rectangle with name of object underlined – shows individual object
and not class of all similar objects
 Lifeline is vertical line under object or actor to show passage of time for object
 Messages use arrows to show messages sent or received by actor or system

Developing a System Sequence Diagram

 Begin with detailed description of use case from fully developed form or activity
diagrams
 Identify input messages
 Describe message from external actor to system using message notation
 Identify and add any special conditions on input message, including iteration and
true/false conditions
 Identify and add output return messages

REFLECTION:
I learned from this lesson that diagrams is very useful in system making. It defines
inputs and outputs and sequence of interactions between user and system for a use case.

Evaluating Alternatives for Requirements,

Environment, and Implementation

SUMMARY:

Project Management Perspective

 Project manager and senior technical members of project team work together
 Eight areas of project management
- Scope
 P a g e | 11

- Time
- Cost
- Quality
- Human resources
- Procurement
- Communications
- Risk

Deciding on Scope and Level of Automation

 Scope determines which business functions will be included in system
 Level of automation is how much computer support exists for functions included in
level
 Scope creep
- Requests for addition of system functions after requirements defined and
decision has been made
- Users typically request more business functions than budget allows
- Event table

Determining the Level of Automation

 Low level
- Simple computer records keeping
 Medium level
- Midrange point which combines features from low and high alternatives
 High level
- System takes over processing of business function

Selecting Alternatives
 Entire group of alternatives is evaluated together to provide “big picture” view of
proposed system
 Key criteria that are used:
- Strategic plan
- Economic feasibility
- Schedule and resource feasibility
- Technological feasibility
- Operational, organizational, and cultural feasibility

Selecting an Implementation Alternative

 Identifying Criteria for Selection
- Comparisons can be difficult
- Different proposed systems have strengths in different areas
 Three major areas to consider
- General requirements
- Technical requirements
 P a g e | 12

- Functional requirements

REFLECTION:
With this chapter, I learned that requirements for evaluation of the system should be
considered. The functionality, technicality and the general requirements of the system should
be considered in the process.