Please see the attached documents and let me know if you have any questions
Business Process Modeling
Before identifying requirements for an information technology solution to
support a process, it is critical to understand how a process is conducted
currently—this is often referred to as the “as‐is” process. Frequently,
people within a process only understand their part of the process and
even within the same group of users, the process may not be consistently
(or correctly) followed. An important first step is to gather representatives
of the process stakeholders to define collectively the current process.
This information can be gathered through stakeholder interviews and/or a
face‐to‐face session where individuals are together and map out the
process on paper throughout the room. In addition to understanding what
is performed in each step, it is important to understand why. For example,
does the information need to be provided to another area in the
organization to enable a related process to be performed?
Once the current process is documented and understood, it’s time to
focus on the best way to perform the series of steps needed to perform a
task—this is referred to as the “to‐be” process. Otherwise, it’s possible to
implement a technology solution that only succeeds in performing a bad
process faster rather than actually gaining the improvements desired to
help achieve the organization’s strategy. The section Business Processes
provides a simple example of a before (as‐is) process and then an
improved (to‐be) process for purchasing textbooks at a college bookstore.
Understanding how a process can best be accomplished lays the
Learning Resource
Business Process Modeling https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
1 of 2 2/7/2023, 5:48 PM
https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learning-resourcelist/business-processmodeling.html?wcmmode=disabled
foundation for defining requirements for a technology solution. Failure to
clearly define all requirements can result in a solution that is incomplete.
This results in a waste of resources and won’t result in the expected
benefits.
© 2023 University of Maryland Global Campus
All links to external sites were verified at the time of publication. UMGC is not responsible for the
validity or integrity of information located at external sites.
Business Process Modeling https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
2 of 2 2/7/2023, 5:48 PM
Business Processes
Introduction
The fourth component of information systems is process. But what is a
process and how does it tie into information systems? And in what ways
do processes have a role in business? This reading will look to answer
those questions and also describe how business processes can be used
for strategic advantage.
What Is a Business Process?
We have all heard the term process before, but what exactly does it
mean? A process is a series of tasks that are completed in order to
accomplish a goal. A business process, therefore, is a process that is
focused on achieving a goal for a business. If you have worked in a
business setting, you have participated in a business process. Anything
from a simple process for making a sandwich at Subway to building a
space shuttle utilizes one or more business processes.
Processes are something that businesses go through every day in order to
accomplish their mission. The better their processes, the more effective
the business. Some businesses see their processes as a strategy for
achieving competitive advantage. A process that achieves its goal in a
unique way can set a company apart. A process that eliminates costs can
Learning Resource
Business Processes https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
1 of 16 2/7/2023, 5:47 PM
https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learning-resourcelist/business-processes.html?wcmmode=disabled
allow a company to lower its prices (or retain more profit).
Documenting a Process
Every day, each of us will conduct many processes without even thinking
about them: getting ready for work, using an ATM, reading our email, etc.
But as processes grow more complex, they need to be documented. For
businesses, it is essential to do this because it allows them to ensure
control over how activities are undertaken in their organization. It also
allows for standardization: McDonald’s has the same process for building
a Big Mac in all of its restaurants.
The simplest way to document a process is to simply create a list. The list
shows each step in the process; each step can be checked off upon
completion. For example, a simple process, such as how to create an
account on eBay, might look like this:
1. Go to ebay.com.
2. Click on “register.”
3. Enter your contact information in the “Tell us about you” box.
4. Choose your user ID and password.
5. Agree to User Agreement and Privacy Policy by clicking on “Submit.”
For processes that are not so straightforward, documenting the process
as a checklist may not be sufficient. For example, here is the process for
determining if an article for a term needs to be added to Wikipedia:
1. Search Wikipedia to determine if the term already exists.
2. If the term is found, then an article is already written, so you must
think of another term. Go to 1.
3. If the term is not found, then look to see if there is a related term.
4. If there is a related term, then create a redirect.
Business Processes https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
2 of 16 2/7/2023, 5:47 PM
5. If there is not a related term, then create a new article.
This procedure is relatively simple—in fact, it has the same number of
steps as the previous example—but because it has some decision points, it
is more difficult to track with a simple list. In these cases, it may make
more sense to use a diagram to document the process:
Wikipedia Term Search Process
Process for determining if a new term should be
added to Wikipedia.
Public Domain
Managing Business Process Documentation
As organizations begin to document their processes, it becomes an
administrative task to keep track of them. As processes change and
improve, it is important to know which processes are the most recent. It is
also important to manage the process so that it can be easily updated!
The requirement to manage process documentation has been one of the
driving forces behind the creation of the document management system.
A document management system stores and tracks documents and
supports the following functions:
Business Processes https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
3 of 16 2/7/2023, 5:47 PM
• Versions and timestamps. The document management system will
keep multiple versions of documents. The most recent version of a
document is easy to identify and will be served up by default.
• Approvals and workflows. When a process needs to be changed, the
system will manage both access to the documents for editing and the
routing of the document for approvals.
• Communication. When a process changes, those who implement the
process need to be made aware of the changes. A document
management system will notify the appropriate people when a
change to a document is approved.
Of course, document management systems are used not only for
managing business process documentation. Many other types of
documents are managed in these systems, such as legal documents or
design documents.
ERP Systems
An enterprise resource planning (ERP) system is a software application
with a centralized database that can be used to run an entire company.
Let’s take a closer look at the definition of each of these components:
Business Processes https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
4 of 16 2/7/2023, 5:47 PM
An Enterprise Resource Planning
(ERP) System
A software application with a centralized
database that can be used to run an
entire company
• A software application: The system is a software application, which
means that it has been developed with specific logic and rules
behind it. It has to be installed and configured to work specifically for
an individual organization.
• With a centralized database: All data in an ERP system is stored in a
single, central database. This centralization is key to the success of
an ERP—data entered in one part of the company can be immediately
available to other parts of the company.
• That can be used to run an entire company: An ERP can be used to
manage an entire organization’s operations. If they so wish,
companies can purchase modules for an ERP that represent different
functions within the organization, such as finance, manufacturing,
and sales. Some companies choose to purchase many modules;
others choose a subset of the modules.
Business Processes https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
5 of 16 2/7/2023, 5:47 PM
PLEASE READ CAREFULLY
– Please use APA (7th edition) formatting
– All questions and each part of the question should be answered in detail (Go into depth)
– Response to questions must demonstrate understanding and application of concepts covered in class,
– Use in-text citations and at LEAST 2 resources per discussion from the school materials that I provided to support all answers. Include at least 2 references and include in-text citations.
– Responses MUST be organized (Should be logical and easy to follow)
Minimum 2 Pages
Discussion 1 – Analyze organizational processes to identify functional requirements
Before responding to this discussion, read Requirements, Developing Requirements for an IT System, and Business Processes. For this discussion, you will practice analyzing processes to identify functional requirements for a system to improve a process. This week’s discussion topic focuses on functional requirements. These need to be clearly written so the people who are developing the system or evaluating a system for use, can discern whether or not the functional requirements are met.
The functional requirements statement:
· Is a complete sentence, with a subject (system) and predicate (intended result, action or condition)
· Identifies only one requirement; does not include the words “and,” “also,” “with,” and “or.”
· States what tasks the system will support or perform
· Includes a measure or metric that can be used to determine whether the functional requirement is met (time or quantity), where appropriate
· Is stated in positive terms and uses “must” (not “may” or “should”); e.g., “the system must xxxx” not “the system must not xxx”
· Avoids the use of terms that cannot be defined and measured, such as “approximately,” “robust,” “user friendly,” etc.
· Must be testable; that is, there must be some way to test the system to determine whether the requirement is met
Questions:
1. Drawing from your own experience,
select a process used at your place of work or other interactions with an organization that you would like to see improved.
Explain why you picked that process.
2. Imagine that a system is to be implemented (or an existing system improved) to make that process better, and
write five (5) functional requirements for the system to perform. Each requirement is one sentence in length and addresses one thing the system must do. We are interested in functional requirements – the activities the system must perform to support the identified process. Use the information above to create your functional requirements statements.
Developing Requirements for an IT
System
Where Do the Requirements Come From?
Let’s assume that someone in the organization identifies one or more
problems with the way a process is working. Whether the current process
is supported by an IT system or not, the analyst might ask people with
different roles in the process two questions:
• What problems are you having in performing the task today?
• How do you see an IT system helping to improve things?
These questions should elicit a variety of responses from multiple
perspectives. The executives might answer with how the organizational
strategies and objectives could be better supported with an IT
system.
Managers may answer the questions with how an IT system would help
them manage the people and processes better. Front‐line employees will
likely focus on their tasks and which steps could be done more easily and
quickly if they had a system. The analyst will use information gathered
during the process analysis phase to help stakeholders identify and clarify
what the system needs to do for them.
If there is organizational agreement that a new system is probably
needed, then a determination should be made as to whether a system will
Learning Resource
Developing Requirements for an IT System https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
1 of 9 2/7/2023, 5:35 PM
https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learning-resourcelist/developing-requirementsforanitsystem.html?
wcmmode=disabled
need to be developed or if a pre‐built commercial off‐the‐shelf (COTS)
solution might work. This would include answering the following types of
questions:
• For what major functions or tasks is the user seeking an IT solution?
• Is there any part of that task that is likely to be unique to this
organization?
• Would it be possible to find a COTS solution, since those are already
created, are ready to be used, and are often much less costly to
implement?
If the organization does not employ any significantly unique functions to
accomplish a standard business process, then it is likely that a COTS
solution exists that could meet the needs. The determination of whether
a system is to be built or bought drives the level of detail needed in the
requirements. Many more requirements with much more detail are
needed for building a system than for buying one.
Regardless of whether a system is to be built or bought, the next step is
to identify the high level user requirements (or “functional”
requirements). This is done by interviewing the expected users of the
system. Users very often know some of what they need the system to do,
but are unable to list all the functions they need. One way the analyst
elicits the requirements is by asking a variety of users at different levels
of the organization and with different responsibilities how the processes
are currently being done and what it is that the current system or process
does or does not do efficiently. The manager’s perspective and needs are
quite different from the front‐line employee trying to perform specific
tasks, and the executive’s perspectives and needs are unique to that level
of the organization. After a series of interviews, the analyst can
categorize and document the requirements that are emerging. Some of
these will likely be at a very high level (e.g., “I need annual financial
reports”) to very low‐level detailed items (e.g., “the zip code must include
all 9 digits”). For an accounting system, the high‐level requirements might
Developing Requirements for an IT System https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
2 of 9 2/7/2023, 5:35 PM
include “the system must implement the Generally Accepted Accounting
Principles (GAAP)” or “the system must produce a monthly expense
statement,” along with many other functions identified by the users. One
of the biggest challenges for the analyst is to differentiate between a
“must have” (essential) requirement and a “nice to have” feature. When
requirements are collected and documented they are often put into these
two categories. The analyst asks the end user to determine whether each
requirement is a “must have” or a “nice to have” item, and documents
accordingly.
Some users may identify requirements that they believe the system must
perform, but that the analyst does not believe should be part of the
specification for the system in question. At this point in the process, all of
the requirements identified by any of the participants should be listed.
Eventually, the full list of requirements will be reviewed, modified as
necessary and approved by the system “owner” and major stakeholders.
During that part of the process, final determinations will be made about
which requirements are essential, which are “nice to have,” and which
should be eliminated. The list of essential requirements will be used to
identify whether there are COTS products available that should be
considered; “nice to have” requirements will be used to compare solutions
that meet the essential requirements. In a system development
environment, the essential requirements will be used to determine the
scope of the project. It is often easier and less costly to include “nice to
have” items in systems being developed in‐house, but the overall cost of
developing and maintaining IT systems must be considered in making that
decision. In the systems development life cycle (SDLC) analysis phase, the
project sponsor signs off on the requirements document. In later SDLC
phases, the requirements are used to design, develop, and test the
system.
A separate set of system performance (system quality and security)
requirements comes from the combination of end user needs as well as
technical specifications developed by the IT department. The answers,
Developing Requirements for an IT System https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
3 of 9 2/7/2023, 5:35 PM
again, are elicited via interviews with expected system users and
managers. Below are example questions that the analyst might ask to
develop system performance requirements in each of the system quality
and security categories:
• Usability—Do you want the system user to have access to an online
help manual? Do you want the user to be able to access context‐
specific help while entering each data field on the screen?
• Scalability—How many users and how many records/transactions do
you need the system to be able to accommodate? How much might
those increase over time?
• Availability—Are there any time blocks where access to the system is
not needed (e.g., no one would use the system between midnight to
4 a.m. daily)?
• Reliability—Can you provide examples of tasks where the system
needs to create and maintain accurate/correct data?
• Maintainability—Are system security updates applied within 24
hours? (While end users are affected by the maintainability of the
system, it is usually up to the IT department to determine whether
the process used accommodates changes as needed and whether
updates are made in a timely manner.)
• Portability—What devices do you want the users of the system to be
able to use? Is it likely that they would use a smartphone, tablet,
etc., to either query or use the system?
• Interoperability—Are there any systems with which the new system
will need to directly exchange data?
• Security—This is another area where users are affected, but need
assistance from technical specialists to determine the requirements.
The analyst might ask: How sensitive is the data? Are there any
regulations concerning protecting the type of data in this system
(personally identifiable information, health care or other data
Developing Requirements for an IT System https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
4 of 9 2/7/2023, 5:35 PM
protected by law, etc.)? Do you want users to be restricted as to
what they can do with the system or what data they can access?
Should this be based on their role in the organization? How often
does the data change? How long could you continue to operate if the
system were unavailable?
The User’s Role—Identifying Requirements
As discussed above, it is the responsibility of the system users to identify
the need for a solution to a problem or to identify processes that could be
improved and performed more effectively or efficiently. The user is
familiar with the business process to be accomplished and with how it is
currently performed, and can identify any issues that exist. Previous work
completed on process analysis is an important precursor to defining
requirements. It is not unusual for the business person to look around and
find potential IT solutions to their problems, and some want to jump
immediately into acquiring a specific solution. However, without a set of
requirements that has been approved by the organization, a solution that
fits one set of problems may not fit the needs of other users of the
system.
The Analyst’s Role—Documenting
Requirements
One of the business analyst’s biggest challenges is to get the users to
identify their requirements rather than focus on a specific solution. The
analyst conducts interviews and observes the process as it exists and
documents the process. Using the process analysis work done previously
and by asking the types of questions discussed above, the analyst gathers
the requirements for the new or updated IT system and begins to
document them.
How Are Requirements Statements Written?
Developing Requirements for an IT System https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
5 of 9 2/7/2023, 5:35 PM
There are a number of “rules” for writing requirements statements. These
rules help to ensure that the requirements can be clearly understood and
that it is possible to determine whether or not the new system meets
each of the requirements. Poorly written requirements lead to
misunderstanding and misinterpretation and can lead to a system that
does not do what the users need it to do.
The analyst uses the list of requirements that the users identified and
rewrites each requirement to meet the criteria listed below.
Each requirement statement:
• Either describes a task that the user needs the system to
perform, or states a system performance expectation.
• Identifies only one requirement; avoids the words “and,” “also,”
“with,” and “or.”
• Is a complete sentence, with a subject (usually “the system”) and
predicate (intended result, action or condition).
• Uses “must” (not “may” or “should” or “will” or “shall”); written as
“The system must….”
• Is generally stated in positive terms (i.e., “the system must xxxx” vs.
“the system must not xxx”); however, there are times when “must
not” is the more appropriate way to express the
requirement.
• Is measurable; includes a measure or metric that can be used to
determine whether the requirement is met (e.g., time or quantity),
where appropriate; avoids the use of terms that cannot be defined
and measured, such as “approximately,” “robust,” “user friendly,” etc.
• Is achievable and realistic; avoids terms such as “100% uptime,” or
“no failures.”
• Is complete; it can stand alone and be understood.
• Must be testable; that is, there must be some way to test the system
Developing Requirements for an IT System https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
6 of 9 2/7/2023, 5:35 PM
to determine whether the requirement is met.
Below are some examples of poorly written and well‐written
requirements, with explanations of what is wrong with the poorly written
requirements statements.
Poorly Written
Requirement What Is Wrong
Well‐Written
Requirement
Users must have access
to their personal data,
which will be
transmitted in a secure
manner.
Two requirements (in
this case, one user and
one system
performance) are
expressed; each
statement should
express only one
requirement.
1.
The system must
provide a user
with access to
their personal
data.
2. The system must
transmit personal
data in a secure
manner.
The system must
calculate the total of all
items in the online or
website shopping cart
and display the total to
the user.
Two requirements are
expressed; each
statement should
express only one
requirement.
1. The system must
calculate the total
of
all items in the
online or website
shopping cart.
2. The system must
display the total of
all items in the
online or website
shopping cart to
the user.
Developing Requirements for an IT System https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
7 of 9 2/7/2023, 5:35 PM
Poorly Written
Requirement What Is Wrong
Well‐Written
Requirement
Report must be
provided within 5
seconds of the user
clicking on
“submit.”
Not a complete
sentence; and should be
stated as “The system
must…”
The system must
provide the report
within 5 seconds of the
user clicking on
“submit.”
The system should
require the user to
provide a shipping
address.
Avoid the use of
“should”; use “must.”
The system must require
the user to provide a
shipping address.
The system must be
easy to use.
“Easy to use” is not
measurable or testable.
The system must
provide on‐screen
prompts to guide the
user through the correct
steps to place an order.
The Requirements Document
Once the requirements statements are written correctly, they should be
grouped into categories. The first categorization is whether a
requirement is essential or nice to have. As stated above, this is done by
asking the individual who identified it as a requirement, rather than using
the analyst’s judgment. Then, the requirements are grouped by the
function or process involved so that the user community can understand
them. Using the accounting system example, the requirements might be
grouped under headings like: accounts receivable, accounts payable,
payroll processing, financial reports, etc. Arranging the requirements in a
sequence that follows the steps in a task is also helpful. For example, in
establishing a receivable account, there are specific steps taken; if the
requirements are listed in the order that is generally used, it allows the
Developing Requirements for an IT System https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
8 of 9 2/7/2023, 5:35 PM
end user to ascertain whether the list of requirements is complete and
accurate. Each requirement statement will be assigned a unique identifier
so that it can be referred to with ease and clarity. A full requirements
document or “requirements specification” may contain many hundreds, or
even thousands, of requirements. Again, more detailed requirements are
needed for systems being built in‐house or under contract. In the case of
selecting a COTS product, only the higher level essential user
requirements and the system performance requirements need to be
developed. Otherwise, if too many specifics are identified, it may be
impossible to find a COTS solution.
If all this documentation of requirements seems like it is very time‐
consuming, it is! Identifying and documenting the requirements is the
basis upon which all further system decisions will be made, so it is a
valuable investment of time and human resources. The later in the
process that requirements changes are introduced, the more costly they
become to implement. In developing a system, it would require the
developers to go back and re‐do portions of the system and re‐test all the
possible outcomes; and, depending on the severity and impact of the
change, it may prove to be extremely costly. For COTS solutions, a
significant change to one or more essential requirements may impact
which systems should even be considered. The upfront investment in
defining the requirements helps prevent downstream costs and delays.
© 2023 University of Maryland Global Campus
All links to external sites were verified at the time of publication. UMGC is not responsible for the
validity or integrity of information located at external sites.
Developing Requirements for an IT System https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
9 of 9 2/7/2023, 5:35 PM
Requirements
What Are Requirements?
For purposes of this class, we will focus on what the end user needs or
expects the system to do. These needs and expectations are documented
as requirements for the system. They fall into two general categories:
user requirements (sometimes referred to as functional requirements) and
system performance requirements (sometimes referred to non‐functional
requirements).
1. User Requirements describe the tasks the user needs the system to
perform, such as:
• What data the system is expected to collect.
• What the system is expected to do with the data that is input.
• What the system is expected to provide as output (reports, results,
etc.).
Some example user requirements for an online shopping site might be:
• The system must calculate the total of all items in the online or
website shopping cart.
• The system must display to the user similar items that the online
shopper may be interested in.
Learning Resource
Requirements https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
1 of 5 2/7/2023, 5:35 PM
https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learning-resourcelist/requirements.html?wcmmode=disabled
• The system must require the user to provide a shipping address.
• The system must automatically fill in the State portion of the
shipping address based on the zip code entered by the user.
• The system must provide the user with a report of all purchases
made via the website.
2. System Performance Requirements are sometimes referred to
as system quality attributes, since they define how the system is
designed, how it will perform when used, and what the user experience
will be (Microsoft, 2009).
They describe how the system will perform, or its quality, in areas such as:
• Usability—The ability for new users to quickly adapt to the software,
including how easy the system is to use and how help is provided for
the users
• Scalability—The ability of the system to accommodate additional
users and/or additional records/transactions
• Availability—The amount or periods of time the system is to be
operational and useable
• Reliability—The ability of the system to create and maintain the data
correctly
• Maintainability—The ability of the system to be easily maintained,
corrected and updated
• Performance—The ability of the system to meet time or volume
requirements (respond to user inquiry, update a database, or handle
the workload)
• Portability—The ability of the system to run/operate on a variety of
end‐user devices or with multiple operating systems
• Interoperability—The ability of the system to interact with other
existing or legacy systems
Requirements https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
2 of 5 2/7/2023, 5:35 PM
System performance requirements also describe security requirements for
the system and data, such as:
• Protection of the system from malicious or accidental actions
• Protection of data as it is transmitted and when it is stored
• User authentication; prevention of unauthorized access
• Authorization of users to perform specific functions; prevention of
unauthorized changes to data
• Data backup and recovery
Some examples of system performance requirements are:
• The system must encrypt the user’s payment information when it is
transmitted.
• The system must require a retinal scan for login purposes.
• The system must be capable of handling 5,000,000 transactions per
hour.
• The system must operate using Motorola handheld scanners.
• The system must be able to accept financial data directly from the
company’s financial system.
To differentiate between user and system performance requirements, the
business analyst determines whether each requirement describes a task
that the system must perform (user requirement) or describes system
quality or security (system performance requirement).
How Are the Requirements Used?
Requirements can be used to develop a system from scratch, in which
case many detailed requirements for every step of every process need to
be clearly laid out. For example, if an accounting system is to be
Requirements https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
3 of 5 2/7/2023, 5:35 PM
developed, the developers will need to incorporate all the financial and
legal aspects of the process. They will need to know exactly how each
accounting function is to be performed in order to program the system to
carry out the function.
However, if the intent is to acquire a commercial off‐the‐shelf (COTS)
accounting system or to use a software‐as‐a‐service (SaaS) system, then
the requirements may be stated at a much higher level, such as: “the
system must implement the Generally Accepted Accounting Principles
(GAAP)” or “the system must produce a monthly expense statement.” In
these cases, the end user is not so concerned about each step in
performing those functions, as long as the system provides them.
Once the requirements are listed, they can be used to:
• Develop a system and test it to be sure it meets the
requirements
• Identify one or more COTS or SaaS systems that appear to meet the
requirements
• Test the COTS or SaaS systems to determine which one meets the
most requirements and select one for use
• Identify requirements that are not met that may need be added to
the system or may require a separate or additional system(s) or
processes to be implemented
According to Mitre (2018) requirements “can be tested, verified, and/or
validated, and are unique, complete, unambiguous, consistent, and
obtainable, and [can be traced] to original business and mission needs.”
Documented requirements can be traced through an entire system
development and implementation process. For example:
• They form the need for a system and define its scope (all the
functions that are to be included).
• They form the basis for estimating the time and cost of developing or
Requirements https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
4 of 5 2/7/2023, 5:35 PM
acquiring the system.
• They are used to develop the system.
• They are used to negotiate any requirements changes that are
proposed by helping to determine how significant the change is.
• They are used to develop test cases to test the system to see if it
functions as needed.
• They are used when modifications or enhancements are proposed to
ensure that the new change does not unintentionally replace
previous functionality, and that the new requirement fits within the
scope of the system’s overall functionality.
• They are used to test a modified system to ensure all previous
functions, as well as the new functions, perform as needed.
References
Microsoft. (2009). Microsoft application architecture guide, 2009.
Retrieved from https://docs.microsoft.com/en‐us/previous‐versions/msp‐
n‐p/ee658094(v=pandp.10)
Mitre. (2018). Systems Engineering Guide—Analyzing and Defining
Requirements. Retrieved from https://www.mitre.org/publications
/systems‐engineering‐guide/se‐lifecycle‐building‐blocks/requirements‐
engineering/analyzing‐and‐defining‐requirements
© 2023 University of Maryland Global Campus
All links to external sites were verified at the time of publication. UMGC is not responsible for the
validity or integrity of information located at external sites.
Requirements https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
5 of 5 2/7/2023, 5:35 PM
Information Systems Development
Introduction
When someone has an idea for a new function to be performed by a
computer, how does that idea become reality? If a company wants to
implement a new business process and needs new hardware or software
to support it, how do they go about making it happen? In this reading, we
will discuss the different methods of taking those ideas and bringing them
to reality, a process known as information systems
development.
Programming
As we learned in Software, it is created via programming. Programming is
the process of creating a set of logical instructions for a digital device to
follow using a programming language. The process of programming is
sometimes called coding because the syntax of a programming language
is not in a form that everyone can understand—it is in “code.”
The process of developing good software is usually not as simple as
sitting down and writing some code. True, sometimes a programmer can
quickly write a short program to solve a need. But most of the time, the
creation of software is a resource‐intensive process that involves several
different groups of people in an organization. In the following sections,
we are going to review several different methodologies for software
Learning Resource
Information Systems Development https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
1 of 26 2/7/2023, 5:37 PM
https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learning-resourcelist/information-systemsdevelopment.html?
wcmmode=disabled
development.
Systems‐Development Life Cycle
The development methodology, systems‐development life cycle (SDLC),
was first developed in the 1960s to manage the large software projects
associated with corporate systems running on mainframes. It is a very
structured and risk‐averse methodology designed to manage large
projects that included multiple programmers and systems that would have
a large impact on the organization.
Various definitions of the SDLC methodology exist, but most contain the
following phases.
1. Preliminary Analysis. In this phase, a review is done of the request. Is
creating a solution possible? What alternatives exist? What is
currently being done about it? Is this project a good fit for our
organization? A key part of this step is a feasibility analysis, which
includes an analysis of the technical feasibility (Is it possible to create
this?), the economic feasibility (Can we afford to do this?), and the
legal feasibility (Are we allowed to do this?). This step is important in
determining if the project should even get started.
2. System Analysis. In this phase, one or more system analysts work
with different stakeholder groups to determine the specific
requirements for the new system. No programming is done in this
step. Instead, procedures are documented, key players are
interviewed, and data requirements are developed in order to get an
overall picture of exactly what the system is supposed to do. The
result of this phase is a system‐requirements document.
3. System Design. In this phase, a designer takes the system‐
requirements document created in the previous phase and develops
the specific technical details required for the system. It is in this
phase that the business requirements are translated into specific
technical requirements. The design for the user interface, database,
Information Systems Development https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
2 of 26 2/7/2023, 5:37 PM
data inputs and outputs, and reporting are developed here. The
result of this phase is a system‐design document. This document will
have everything a programmer will need to actually create the
system.
4. Programming. The code finally gets written in the programming
phase. Using the system‐design document as a guide, a programmer
(or team of programmers) develop the program. The result of this
phase is an initial working program that meets the requirements laid
out in the system‐analysis phase and the design developed in the
system‐design phase.
5. Testing. In the testing phase, the software program developed in the
previous phase is put through a series of structured tests. The first is
a unit test, which tests individual parts of the code for errors or bugs.
Next is a system test, where the different components of the system
are tested to ensure that they work together properly. Finally, the
user‐acceptance test allows those that will be using the software to
test the system to ensure that it meets their standards. Any bugs,
errors, or problems found during testing are addressed and then
tested again.
6. Implementation. Once the new system is developed and tested, it
has to be implemented in the organization. This phase includes
training the users, providing documentation, and conversion from
any previous system to the new system. Implementation can take
many forms, depending on the type of system, the number and type
of users, and how urgent it is that the system become operational.
These different forms of implementation are covered later in this
reading.
7. Maintenance. This final phase takes place once the implementation
phase is complete. In this phase, the system has a structured support
process in place: reported bugs are fixed and requests for new
features are evaluated and implemented; system updates and
backups are performed on a regular basis.
Information Systems Development https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
3 of 26 2/7/2023, 5:37 PM
SDLC Waterfall
Seven phases of the systems‐
development life cycle
methodology
The SDLC methodology is sometimes referred to as the waterfall
methodology to represent how each step is a separate part of the
process; only when one step is completed can another step begin. After
each step, an organization must decide whether to move to the next step
or not. This methodology has been criticized for being quite rigid. For
example, changes to the requirements are not allowed once the process
has begun. No software is available until after the programming phase.
Again, SDLC was developed for large, structured projects. Projects using
SDLC can sometimes take months or years to complete. Because of its
inflexibility and the availability of new programming techniques and tools,
many other software‐development methodologies have been developed.
Many of these retain some of the underlying concepts of SDLC, but are
not as rigid.
Information Systems Development https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
4 of 26 2/7/2023, 5:37 PM
The RAD Methodology
Rapid application development
methodology
Public Domain
Rapid application development (RAD) is a software‐development (or
systems‐development) methodology that focuses on quickly building a
working model of the software, getting feedback from users, and then
using that feedback to update the working model. After several iterations
of development, a final version is developed and implemented.
The RAD methodology consists of four phases:
1. Requirements Planning. This phase is similar to the preliminary‐
analysis, system‐analysis, and design phases of the SDLC. In this
phase, the overall requirements for the system are defined, a team is
identified, and feasibility is determined.
2. User Design. In this phase, representatives of the users work with
the system analysts, designers, and programmers to interactively
create the design of the system. One technique for working with all
of these various stakeholders is the so‐called JAD session. JAD is an
acronym for joint application development. A JAD session gets all of
the stakeholders together to have a structured discussion about the
design of the system. Application developers also sit in on this
meeting and observe, trying to understand the essence of the
requirements.
Information Systems Development https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
5 of 26 2/7/2023, 5:37 PM
Requirements
What Are Requirements?
For purposes of this class, we will focus on what the end user needs or
expects the system to do. These needs and expectations are documented
as requirements for the system. They fall into two general categories:
user requirements (sometimes referred to as functional requirements) and
system performance requirements (sometimes referred to non‐functional
requirements).
1. User Requirements describe the tasks the user needs the system to
perform, such as:
• What data the system is expected to collect.
• What the system is expected to do with the data that is input.
• What the system is expected to provide as output (reports, results,
etc.).
Some example user requirements for an online shopping site might be:
• The system must calculate the total of all items in the online or
website shopping cart.
• The system must display to the user similar items that the online
shopper may be interested in.
Learning Resource
Requirements https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
1 of 5 2/7/2023, 5:35 PM
https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learning-resourcelist/requirements.html?wcmmode=disabled
• The system must require the user to provide a shipping address.
• The system must automatically fill in the State portion of the
shipping address based on the zip code entered by the user.
• The system must provide the user with a report of all purchases
made via the website.
2. System Performance Requirements are sometimes referred to
as system quality attributes, since they define how the system is
designed, how it will perform when used, and what the user experience
will be (Microsoft, 2009).
They describe how the system will perform, or its quality, in areas such as:
• Usability—The ability for new users to quickly adapt to the software,
including how easy the system is to use and how help is provided for
the users
• Scalability—The ability of the system to accommodate additional
users and/or additional records/transactions
• Availability—The amount or periods of time the system is to be
operational and useable
• Reliability—The ability of the system to create and maintain the data
correctly
• Maintainability—The ability of the system to be easily maintained,
corrected and updated
• Performance—The ability of the system to meet time or volume
requirements (respond to user inquiry, update a database, or handle
the workload)
• Portability—The ability of the system to run/operate on a variety of
end‐user devices or with multiple operating systems
• Interoperability—The ability of the system to interact with other
existing or legacy systems
Requirements https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
2 of 5 2/7/2023, 5:35 PM
System performance requirements also describe security requirements for
the system and data, such as:
• Protection of the system from malicious or accidental actions
• Protection of data as it is transmitted and when it is stored
• User authentication; prevention of unauthorized access
• Authorization of users to perform specific functions; prevention of
unauthorized changes to data
• Data backup and recovery
Some examples of system performance requirements are:
• The system must encrypt the user’s payment information when it is
transmitted.
• The system must require a retinal scan for login purposes.
• The system must be capable of handling 5,000,000 transactions per
hour.
• The system must operate using Motorola handheld scanners.
• The system must be able to accept financial data directly from the
company’s financial system.
To differentiate between user and system performance requirements, the
business analyst determines whether each requirement describes a task
that the system must perform (user requirement) or describes system
quality or security (system performance requirement).
How Are the Requirements Used?
Requirements can be used to develop a system from scratch, in which
case many detailed requirements for every step of every process need to
be clearly laid out. For example, if an accounting system is to be
Requirements https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
3 of 5 2/7/2023, 5:35 PM
developed, the developers will need to incorporate all the financial and
legal aspects of the process. They will need to know exactly how each
accounting function is to be performed in order to program the system to
carry out the function.
However, if the intent is to acquire a commercial off‐the‐shelf (COTS)
accounting system or to use a software‐as‐a‐service (SaaS) system, then
the requirements may be stated at a much higher level, such as: “the
system must implement the Generally Accepted Accounting Principles
(GAAP)” or “the system must produce a monthly expense statement.” In
these cases, the end user is not so concerned about each step in
performing those functions, as long as the system provides them.
Once the requirements are listed, they can be used to:
• Develop a system and test it to be sure it meets the
requirements
• Identify one or more COTS or SaaS systems that appear to meet the
requirements
• Test the COTS or SaaS systems to determine which one meets the
most requirements and select one for use
• Identify requirements that are not met that may need be added to
the system or may require a separate or additional system(s) or
processes to be implemented
According to Mitre (2018) requirements “can be tested, verified, and/or
validated, and are unique, complete, unambiguous, consistent, and
obtainable, and [can be traced] to original business and mission needs.”
Documented requirements can be traced through an entire system
development and implementation process. For example:
• They form the need for a system and define its scope (all the
functions that are to be included).
• They form the basis for estimating the time and cost of developing or
Requirements https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
4 of 5 2/7/2023, 5:35 PM
acquiring the system.
• They are used to develop the system.
• They are used to negotiate any requirements changes that are
proposed by helping to determine how significant the change is.
• They are used to develop test cases to test the system to see if it
functions as needed.
• They are used when modifications or enhancements are proposed to
ensure that the new change does not unintentionally replace
previous functionality, and that the new requirement fits within the
scope of the system’s overall functionality.
• They are used to test a modified system to ensure all previous
functions, as well as the new functions, perform as needed.
References
Microsoft. (2009). Microsoft application architecture guide, 2009.
Retrieved from https://docs.microsoft.com/en‐us/previous‐versions/msp‐
n‐p/ee658094(v=pandp.10)
Mitre. (2018). Systems Engineering Guide—Analyzing and Defining
Requirements. Retrieved from https://www.mitre.org/publications
/systems‐engineering‐guide/se‐lifecycle‐building‐blocks/requirements‐
engineering/analyzing‐and‐defining‐requirements
© 2023 University of Maryland Global Campus
All links to external sites were verified at the time of publication. UMGC is not responsible for the
validity or integrity of information located at external sites.
Requirements https://leocontent.umgc.edu/content/umuc/tus/ifsm/ifsm300/2228/learni…
5 of 5 2/7/2023, 5:35 PM
Order an Essay Now & Get These Features For Free:
Turnitin Report
Formatting
Title Page
Citation
Outline
