UNRESTRICTED
ITSD008
System Development
Techniques
© 2022 Singapore Institute of Management Group Limited
Lesson 2
System Requirements
© 2022 Singapore Institute of Management Group Limited
Learning outcomes
After studying this chapter and the recommended reading, you
should be able to:
• Discuss the systems requirements
• Discuss the information-gathering techniques
• Explain the documenting workflows with
activity diagrams
Systems Analysis Activities
• Third core process,
– discover and understand the details.
– aka systems analysis.
Source: Satzinger, Robert & Stephen Chapter 2
Systems Analysis Activities
• The activities are as follows:
– Gather detailed information.
– Define requirements.
– Prioritize requirements.
– Develop user-interface dialogs.
– Evaluate requirements with users.
• By completing these activities, the analyst defines in great
detail what the information system needs to accomplish to
provide the organization with the desired benefits.
Gather Detailed Information
• Systems analysts (SA) obtain information from people by
– interviewing or
– watching them work.
• Obtain additional information by
– reviewing planning documents and policy statements
– study existing systems, including their documentation
– looking at what other companies (particularly
vendors) have done when faced with a similar
business need.
Gather Detailed Information
– try to understand an existing system by identifying
and understanding activities of all the current and
future users
• SA must become an expert in that business
area.
– For example, to implement a loan-processing system, the SA needs to
become an expert on the rules used for approving credit.
• The most successful SA become experts in their
organization’s main business.
Define Requirements
• Uses gathered information to define
requirements for the new system.
• System requirements include
– functions the system must perform (functional
requirements) and such related issues
– user-interface formats
– requirements for reliability, performance, and
security (non functional requirements).
Define Requirements
• Creates models to record requirements.
– Example of models: use case diagrams, activity
diagrams, and domain model class diagrams.
• Reviews the models with users
• Refines and expands the models to reflect
new or updated information.
Prioritize Requirements
• Establish which requirements are most crucial for the
system.
• Sometimes, users request additional system
functions that are desirable but not essential.
• Need to ask which functions are truly important and
which are fairly important but not absolutely
required.
• Resources are always limited, it is important to know
what is absolutely required.
Prioritize Requirements
• Scope Creep: System requirements tend to expand as
users make more suggestions
• Requirements priorities help to determine the
number, composition, and ordering of project
iterations.
• High-priority requirements are often incorporated
into early project iterations so analysts and users
have ample opportunity to refine those parts of the
system.
Develop User-Interface Dialogs
• User evaluating a user interface is an easy and
simpler way to get feedback and gather information
because the user can see and feel the system.
• To most users, the user interface is all that matters.
• Developing user-interface dialogs (wireframe) is a
powerful method to document requirements.
Develop User-Interface Dialogs
• SA can
– develop user interfaces via abstract models, such
as interaction diagrams and written dialogs, or
– Develop storyboards or user-interface prototypes
on the actual input/output devices that users will
use (e.g., a computer monitor, iPad, or
smartphone).
Develop User-Interface Dialogs
• A prototype interface can serve as a requirement and
a starting point for developing a portion of the
system.
• A user-interface prototype developed in an early
iteration can be expanded in later iterations to
become a fully functioning part of the system.
Evaluate Requirements with Users
• SA usually use an iterative process to get user input
to model requirements, return to the user for
additional input or validation/feedback, and then
incorporate the new inputs and refine the models.
• The processes of getting requirements, building
models and prototypes, and evaluating them with
users may repeat many times until requirements
models and prototypes are complete and accurate.
System Requirements
• System requirements
– all the activities the new system must perform or
support and the constraints that the new system
must meet.
• Two categories:
– functional and non-functional requirements.
Functional requirements
• Activities that the system must perform (i.e., the
business uses to which the system will be applied).
• For example, a payroll system, the required business
uses might include such functions as
– “generate electronic fund transfers,”
– “calculate commission amounts,”
– “calculate payroll taxes,”
– “maintain employee-dependent information,”,
Non-functional requirements
• Characteristics of the system other than those
activities it must perform or support.
• FURPS
– functional, usability, reliability, performance, and
security.
• Functional: same as functional requirements defined
previously.
FURPS
• Usability requirements
– operational characteristics related to users, such
as the user interface, related work procedures,
online help, and documentation.
• For example, the user interface for a smartphone app
should behave similarly to other apps when responding
to such gestures as two-finger slides, pinching, and
expanding.
• Additional requirements might include menu format,
colour schemes, use of the organization’s logo, and
multilanguage support.
FURPS
• Reliability requirements
– how often a system exhibits such behaviours as
service outages and incorrect processing and how
it detects and recovers from those problems.
FURPS
• Performance requirements
– operational characteristics related to measures of
workload, such as throughput and response time.
– For example, the client portion of a system might
be required to have a 0.5 second response time to
all button presses, and the server might need to
support
FURPS
• Security requirements
– how access to the application will be controlled
and how data will be protected during storage and
transmission.
– For example, the application might be password
protected, encrypt locally stored data with 1024-
bit keys, and use secure HTTP for communication
among client and server nodes.
Stakeholders
• People who have an interest in the successful
implementation of the system.
• For example, accounting system the
stakeholders
– bookkeepers, accountants, managers and
executives, customers, suppliers, auditors,
investors.
Stakeholders
• Each stakeholder group interacts with the system in
different ways,
• Each has a unique perspective on system
requirements.
• Before gathering detailed information, the analyst
identifies every type of stakeholder who has an
interest in the new system and ensures that critical
people from each stakeholder category are available
to serve as the business experts.
Information-Gathering Techniques
• The following are common Information-
Gathering Techniques
• Interviewing users and other stakeholders
• Distributing and collecting questionnaires
• Reviewing inputs, outputs, and documentation
• Observing and documenting business procedures
• Researching vendor solutions
• Collecting active user comments and suggestions
Interviewing users and other
stakeholders
• Effective way to understand business functions and business
rules.
• Most time- consuming and resource-expensive option.
• SA does the following:
– Prepare detailed questions
– Meet with individuals or groups of users
– Obtain and discuss answers to the questions
– Document the answers
– Follow up as needed in future meetings or interviews
• Process may take some time, usually requires multiple
sessions with each of the users or user groups.
Distributing and collecting
questionnaires
• Enable SA to collect information from a large number
of stakeholders.
• Even if the stakeholders are widely distributed
geographically, they can still help define
requirements through questionnaires.
• Used to obtain preliminary insight into stakeholder
information needs, which helps to determine areas
that need further research using other methods.
Reviewing inputs, outputs, and
documentation
• Two sources of documentation. (External and
Internal)
– External to the organization
• industry-wide professional organizations and other
companies.
• may not be easy to obtain information from other
companies,
• may be available in industry journals and magazines
report the findings of “best practices” studies.
Reviewing inputs, outputs, and
documentation
- Internal to the organization
• revieing internal documents and procedures.
• good way to get a preliminary understanding of the
processes.
• serve as visual aids for the interview and as the working
documents for discussion
• helps identify business rules that may not come up in the
interviews.
• helps reveal discrepancies and redundancies in the business
processes.
• However, procedure documents frequently are not kept up
to date, and they commonly include errors. SA should review
them with the users.
Observing and documenting
business procedures
• observing business process in action helps to
understand the current business functions and
fundamental business needs,
• the processes could and often should change to be
made more efficient.
• do not get locked into believing there is only one way
of performing the process.
Researching vendor solutions
• Consulting firms often have experience with the
same problems,
• Software firms may have packaged solutions for a
particular business need.
• Taking advantage of existing knowledge or solutions
can avoid costly mistakes and save time and money.
Collecting active user comments
and suggestions
• Portions of the system are constructed and tested during each
iteration.
• Users and other stakeholders perform the initial testing of
system functions during the iteration in which those functions
are implemented.
• They also test and use those same functions during later
iterations.
• User feedback from initial and later testing is a valuable
source of requirements information
Models
• A model is a representation or abstraction of some aspect of
the system being built.
• There are dozens of different models that an analyst or
designer might develop and use
Source: Satzinger, Robert & Stephen Chapter 2
Documenting Workflows with
Activity Diagrams
• One effective way to capture workflow is with a UML
activity diagram.
• An activity diagram describes the various user (or
system) activities, the person or component that
completes each activity, and the sequential flow of
these activities.
Documenting Workflows with
Activity Diagrams
• Activity diagram basic symbols
Source: Satzinger, Robert & Stephen Chapter 2
Documenting Workflows with
Activity Diagrams
• The flattened ovals represent the individual activities
in a workflow.
• The connecting arrows represent the sequence of
the activities.
• The black circles denote the beginning and the
ending of the workflow.
• The diamond is a decision point at which the flow of
the process will either follow one path or another.
Documenting Workflows with
Activity Diagrams
• The heavy solid line is a synchronization bar, which
either splits the path into multiple concurrent paths
or recombines concurrent paths.
• The swimlane represents an agent who performs the
activities.
– each agent follows a path parallel with other agents in the
workflow, as with swimmers in a swimming pool.
Documenting Workflows
with Activity Diagrams
• Order fulfillment process
Source: Satzinger, Robert & Stephen Chapter 2
Documenting Workflows
with Activity Diagrams
• Processing begins when the
customer has completed the
order checkout process and
the warehouse begins order
fulfillment.
• Omits many error-handling
path- ways, including what
happens if enough item stock
is on hand to fulfill only part of
an order.
Source: Satzinger, Robert & Stephen Chapter 2
Documenting Workflows
with Activity Diagrams
• Ordering a product that
has to be manufactured
to match customer
specifications.
Source: Satzinger, Robert & Stephen Chapter 2
Documenting Workflows
with Activity Diagrams
• To show that the
salesperson sends the
order to Engineering, the
diagram uses a new
symbol to emphasize the
transmission of the
document between Sales
and Engineering.
Source: Satzinger, Robert & Stephen Chapter 2
Documenting Workflows
with Activity Diagrams
• After Engineering
develops the
specifications, two
concurrent activities
happen: Purchasing
orders the materials, and
Production writes the
program for the
automated milling
machines.
Source: Satzinger, Robert & Stephen Chapter 2
Documenting Workflows
with Activity Diagrams
• These two activities are
completely independent
and can occur at the same
time.
• Notice that one
synchronization bar splits
the path into two
concurrent paths and that
another synchronization
bar reconnects them.
Source: Satzinger, Robert & Stephen Chapter 2
Documenting Workflows
with Activity Diagrams
• Finally, Scheduling puts
the order on the
Production schedule.
Source: Satzinger, Robert & Stephen Chapter 2
Summary
• System analysis activities are as follows:
– Gather detailed information.
– Define requirements.
– Prioritize requirements.
– Develop user-interface dialogs.
– Evaluate requirements with users.
Summary
• The following are common Information-
Gathering Techniques
• Interviewing users and other stakeholders
• Distributing and collecting questionnaires
• Reviewing inputs, outputs, and documentation
• Observing and documenting business procedures
• Researching vendor solutions
• Collecting active user comments and suggestions
Summary
• One effective way to capture workflow is with a UML activity
diagram.
• An activity diagram describes the various user (or system)
activities, the person or component that completes each
activity, and the sequential flow of these activities.
Source: Satzinger, Robert & Stephen Chapter 2
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 2
Thank you
