FAM601 Teknologi dan Layanan Informasi Kefarmasian

Semester Genap 2021/2022

Analisis Kebutuhan
Sistem Informasi
Requirements
Engineering

S2 Ilmu Farmasi, Fakultas Farmasi

Universitas Airlangga

Ira Puspitasari, Ph.D.

Requirements Engineering
Involves all tasks that are conducted to identify the
needs of different stakeholders

2
System Development Lifecycle
Source:
https://www.innovativearchitects.com/KnowledgeCenter/basic-IT-
systems/system-development-life-cycle.aspx

3
 • Analysis of problem to be solved by new system
• Defining the problem and identifying causes
• Specifying solutions
• Identifying information requirements

• Establishing information requirements

• Who needs what information, where, when, and how

• Define objectives of new/modified system

SDLC: • Detail the functions new system must perform

• Faulty requirements analysis is leading cause

Analysis and of systems failure and high systems
Requirements development cost.
• Problem of volatility

4
 Requirements Engineering:
• determining the needs or conditions to meet for a new
or altered product or project,
• taking account of the possibly conflicting requirements
of the various stakeholders,
• analyzing, documenting, validating and managing
software or system requirements.

System (software) requirements:

SDLC: • a capability that must be met or possessed by a system
Analysis and or system component to satisfy a contract, standard,
specification, or other formally imposed documentation.
Requirements • the requirements should be documented, actionable,
measurable, testable, traceable, related to identified
business needs or opportunities, and defined to a level
of detail sufficient for system design.
5
 Business Process Analysis
Business Process
Analysis and Modeling

Problem Discovery and

Analysis
SDLC:
Analysis &
Requirements
Require- Identification

ments Requirements Analysis

and Documentation
System Requirements Analysis
6
Requirements
Identification On-site
observation
Firm Documen-
tation, standard,
policy

Interview
Question-
with
naire
stakeholders

Business Information
Process Prototyping
Model Gathering

7
 Functional Requirements:
• Describe high-level statements of what the system
should do (functional) and the system services in detail.
• Depend on the type of information system and expected
users.

Non-functional requirements:
• Product requirements: the delivered product must
behave in a particular way e.g. execution speed,
reliability, etc.

Types of • Organisational requirements: address organisational

policies and procedures e.g. process standards used,
Requirements implementation requirements, etc.
• External requirements: from external organisation /
system and its development process e.g. interoperability
requirements, legislative requirements,
8
 • Requirements analysis tools: Unified Modeling
Language (UML), procedural model, process
based model, data flow model, etc.
• UML:
• a general-purpose, developmental, modeling
language in the field of software engineering,
• provide a standard way to visualize the design of
a system.
• UML is a notation, not a methodology
Requirements • UML has become a world standard

Analysis • 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.
9

Requirements
Analysis:
Use Case Model
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.
• Represent the requirements of the system
• A model of the interaction between external users of an
information system (actors) and the information system itself.
• 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
management system development activities.
• Provides aid in estimating project scope, effort, schedule.
• Provides baseline for user documentation, identification of data
objects or entities, specifications for designing user and system
interfaces.
• Provides framework for driving the system development project.
10
Requirements Analysis: Use Case Model
Actor
• a person, a company / organization, a computer
program, information system, a business entity.
• interact directly with the system.

Use Case
• Represents the actions performed by one or more
actors in the pursuit of a particular goal
• How the actor uses the system

Association / Relationship
• Relation between actor and use case

• Indicates that an actor takes part in a use case

11
Requirements
Analysis:
Use Case Model
Example of ATM Use Case

12
 <<include>>
• a directed relationship between two use cases which is
used to show that behavior of the included use case (the
Requirements addition) is inserted into the behavior of the including (the
base) use case.
Analysis:
Use Case Model
<<extend>>
Stereotypes of Association
• a directed relationship that specifies how and when the
between Use Case
behavior defined in usually supplementary
(optional) extending use case can be inserted into
the behavior defined in the extended use case.

13
Requirements Analysis: Use Case Model
Generalization between Use Cases Generalization between Actors
• Generalization between use cases is similar • one actor can inherit the role of the other
to generalization between classes – child use actor. The descendant inherits all the use
case inherits properties and behavior of the cases of the ancestor.
parent use case and may override the
behavior of the parent.

14
Requirements
Analysis:
Use Case
Model

Example of ATM
Use Case 2
15
 • When looking for actors, ask the following
questions:

Requirements • Who or what provides inputs to the system?

• Who or what receives outputs from the system?
Analysis: • Are interfaces required to other systems?
Use Case Model • Are there events that are automatically triggered at a
predetermined time?
Step 1: • Who will maintain information in the system?
Identify Business Actors • Who uses the system?

• Actors should be named with a noun or noun

phrase

16
 • Business Requirements Use Case - a use case created during
requirements analysis to capture the interactions between a
user and the system free of technology and implementation
Requirements details.

Analysis: • During requirements analysis, strive to identify and

document only the most critical, complex, and important
Use Case Model use cases: essential use cases.
• When looking for use cases, ask the following questions:
Step 2: • What are the main tasks of the actor?
Identify Business Use Cases • What information does the actor need form the system?
• What information does the actor provide to the system?
• Does the system need to inform the actor of any changes or
events that have occurred?
• Does the actor need to inform the system of any changes or
events that have occurred?
17
Requirements
Analysis:
Use Case
Model

Step 3:
Constructs Use
Case Diagram
18
 • Document first at high level to quickly obtain an
understanding of the events and magnitude of the system.
• Expand to a fully-documented business requirement
Requirements narrative.
Analysis: • Include the use case’s typical course of events and its

Use Case Model alternate courses.

Step 4:
Document Business
Requirements Use-Case
Narratives

19
20
21
 Information System Requirements Specification
• A formal document that communicates the requirements of
a proposed system to key stakeholders and serves as a
contract for the systems project.

Requirements • Content
• Introduction: purpose, scope, background, reference, list of
Documentation terms and abbreviations.
• General System Description
• List of Requirements: functional, non functional
• Conclusion, Appendix

Functional
Requirements

Use Case Activity Narrative

Use Case
Scenario Diagram * Description
22
 • The system may cost more than projected.

• The system may be delivered later than promised.

Incorrect • The system may not meet the users’ expectations and
they may not to use it.
Requirements
• Once in production, costs of maintaining and
enhancing system may be excessively high.
• The system may be unreliable and prone to errors and
downtime.
• Reputation of IT staff is tarnished as failure will be
perceived as a mistake by the team.

23