Introduction to System Development

Wednesday, 19 June 2024 23:33

C1: Overview of Systems Analysis and Design

Information System- a set of interrelated components that collect,
process, store and provide output as the information needed to
complete business tasks, this includes the people who operate the
system and carry out the work.

Computer Application- software program that carries out the

specific function or set of related functions on a computing device.

System analysis- activities that enable a person to understand and

specify what the new system should accomplish. (what a system
must do)

System Design- activities that enable a person to describe how the

system will be implemented. (how the system will work)

System development life cycle (SDLC)

The beginning development of a new information system is usually done as a

project. Meaning activities required for development are identified, planned,
organised and monitored.

Project- planned effort with a defined start and finish that results in a specific
outcome.

System development life cycle- project management framework that

identifies all the activities that required to research, build, deploy and
maintain information systems.

Six Core Processes

Identify- Pinpoint the problem and obtain the approval to proceed with the
project.
Pan and Monitor- what to do, how to do it and who does it.

New Section 1 Page 1

Pan and Monitor- what to do, how to do it and who does it.
Discover- Understand the details of the problem and what is required.
Design- How will it actually work.
Build- Test and integrate systems components (lots of programming).
Complete- Finalise system test and deploy solutions.

System development process/ methodology- set of comprehensive guidelines

for carrying out all of the activities of each core process of the SDLC.

Agile development- emphasizes flexibility and rapid response to anticipate new and
changing requirements during development.

Iterative development-the system is “grown” piece by piece through multiple mini

projects called iterations

Iterative Development Process

Core components are developed initially, followed by the addition of extra components.
This method is termed iterative because the six core development processes are
repeated for each component. Essentially, it involves one large project made up of a
series of mini-projects, where the information system is incrementally built piece by
piece during these mini-projects.

Iteration 1- appears to primarily focus on identifying the problem and planning the
project. Lesser amounts of discovery, design, and build/test may also be done. For this
iteration, nothing is done with regard to deploying the system.

New Section 1 Page 2

iteration, nothing is done with regard to deploying the system.
Iteration 2- there is less effort for identifying the problem and planning the project and
more effort for discovery, design, and build/test.
Iteration 3- build/test gets the most effort, but all six core processes are still involved,
including the beginnings of completing and deploying the system.

Benefits
1- Parts of the system can be deployed earlier, providing basic support to users sooner.
2- Tackling small portions of the project first helps identify and resolve difficult problems
early on. (Useful for large and complex systems where managing all requirements at
once is impractical)
3- Iterative development enhances flexibility, allowing the project to adapt to new
requirements and issues as they arise.

Sample Project RMO

1st Iteration- 3 major objectives: get project approval, get clear picture of system's
overall vision (function and data requirements), develop detailed specifications and
create a solution for a specific portion of the system (i.e., analyse, design, build, and test
one part of the system).

2nd and 3rd Iteration- continue to work on the additional portions of the system based
on the system vision.

Beginning Project Activities

Before the project actually begins, pre-project activities of Core Process 1 need to be
established.
• Identify the problem and document the objective of the solution system.
• Obtain approval to commence the project.

System Vision Document - identify the benefits to the company and the functional
capabilities that will be included in the system.
Done in two steps:
• Developing a preliminary statement of benefits
• Adding estimates of specific dollar costs and dollar benefits

New Section 1 Page 3

Plan and monitor the project—includes business analysis and project management activities. These Core
Process 2 activities completed on Day 1:
• Determine the major components (functional areas) that are needed.
• Define the iterations and assign each functional area to an iteration.
• Determine team members and responsibilities.
The project team meets with users to discuss business needs and system objectives, using the System
Vision Document as a starting point. The list of system capabilities helps determine the overall project
plan.

1st activity is to divide the system into several subsystems or components.

Subsystem- fully functional part of a complete system.

RMO subsystems:
• Supplier Information Subsystem- collect and maintain information about the manufacturers or
wholesalers and the contact people who work for them.
• Product Information Subsystem- will capture information about the various products offered by
the manufacturers or wholesalers, including detailed descriptions and photographs.

2nd activity is to identify the order in which the subsystems will be developed.
• Supplier Information Subsystem should be scheduled for the first iteration
• Product Information Subsystem should be scheduled for the second iteration.
• The third and fourth iterations would complete the implementation, testing, and deployment of

New Section 1 Page 4

 • The third and fourth iterations would complete the implementation, testing, and deployment of
the system based on what was initially implemented in the first two iterations.
The Supplier System

Planning process for an iteration consists of these three steps:

• Identify the tasks required for the iteration.
• Organize and sequence these tasks into a schedule called a work breakdown structure (WBS)
• Identify required resources (especially people), and assign people to tasks.

Take the tasks from the WBS an place them on a day-to-day sequence called a iteration schedule

New Section 1 Page 5

Fact Finding and User Involvement- involves discovering and understanding details, which is a key part
of systems analysis.
Core Process 3 activities completed on Day 2:
• Do fact-finding tasks to understand the requirements.
• Develop a list of use cases and a use case diagram.
• Develop a list of classes and a class diagram.

1st activity includes interviewing key users, observing existing processes, reviewing documentation and
systems, and researching other companies.

2nd activity is to identifying and describing use cases is the way to document what the users need to do
with the system

New Section 1 Page 6

3rd activity involves creating domain classes, these represent the real-world objects or concepts that a
system needs to track. During discussions with purchasing agents, domain classes are identified by
noting nouns that describe categories, such as suppliers, products, or inventory items.

Analyse in detail the use cases and domain classes

Core Process 3 activities for Day 3:
• Perform in-depth fact finding to understand details of each use case.
• Understand and document the detailed workflow of each use case.
• Define the user experience with sketches of screens and reports needed for each use case.

New Section 1 Page 7

Activity 1 determines the use cases and create the corresponding diagram
• Look up supplier
• Enter/update supplier information
• Look up contact information
• Enter/update contact information

Activity 2 is documenting the details of a use case, either via case description or an activity diagram that
shows all the steps in a use case.

Use case description- how the user interacts and uses the system to carry out a specific work task for a
single use case

New Section 1 Page 8

Activity 3 involves defining screen layout, this user-interface design includes creating how a system looks
and how the user interacts with it. A well-designed user interface—one that is intuitive and easy to use,
has a full range of features to facilitate navigation, and provides good information— will enhance the
utility of the system

New Section 1 Page 9

Designing the solution system components- high-level system structure and individual programs are
designed by identifying subsystems and connections, and then detailing program modules like the user
interface, business logic, and database access.
Core Process 4 day 4 activities:
• Design the database structure (schema).
• Design the system’s high-level structure

1st activity Designing the database uses the information provided by the domain class diagram to
determine the tables, the columns in the tables, and other components, its either done for the entire
systems or by subsystem, or piecemeal (use case by use case)

A General Approach to Design

• Use cases, with activity diagrams

New Section 1 Page 10

 • Use cases, with activity diagrams
• Domain classes, with accompanying diagrams
• Pages and reports, with program and display logic specifications

To program, we need to know what the classes are, what the logic is within each class (i.e., the
functions), and which classes must interact.

Defining the Preliminary Design Class Diagram

System will be built by using object-oriented programming (OOP) techniques, beginning with developing
the set of software classes and their methods that will be needed for the system.

New Section 1 Page 11

Designing Subsystem Software Architecture
Once the overall structure and approach for implementing the new system, we begin to drill down to
the software design for the subsystem. One of the advantages of partitioning the system into layers is it
is much easier to build and maintain with this kind of structure given its modular format.

New Section 1 Page 12

The View layer includes two classes that represent what is seen on the user interface—SupplierView and
ContactView—as well as some JavaScript functions. The Domain layer includes two classes that interact
with each other and with the database—Supplier and Contact.

Day 5 activities
• Create detail design.
• Program the subsystem components
Day 6 activities
• Final testing

New Section 1 Page 13

Systems Analysis Activities
Thursday, 20 June 2024 00:06

C2: Investigating System Requirements

technology architecture- the set of computing hardware, network
hardware and topology, and system software—such as operating and
database management systems—employed by an organization.
Desktop computers, web sites, LANs, WANs, VPNs

application architecture- the set of information systems (the software

applications) the organization needs to support its strategic plan.

• Supply chain management (SCM). using Java and Oracle. It

supports inventory control, purchasing, and distribution, although
integration of functions needs improvement.
The new Tradeshow System will interface with this system.
• Phone/mail order system. using Visual Studio and Microsoft SQL
Server. A quick solution to customer demand for phone and mail
orders.
It is integrated with the SCM and has reached capacity.
• Retail Store System (RSS). using point-of-sale processing. It
facilitates realtime inventory updates to/from the SCM.
• Customer Support System (CSS). Internet storefront, supporting
customer inquiries, shopping cart, order tracking, shipping, back
orders, and returns
Consolidated Sales and Marketing System (CSMS). modernize the
technology and functionality of the CSS and to add more customer
oriented functionality.

Systems Analysis Activities

Analysis activities from Core process 3

• Gather detailed information.

• Define requirements.
• Prioritize requirements.
• Develop user-interface dialogs.
• Evaluate requirements with users

Gather detailed information

Systems analysts gather information from system users through interviews and observations,
talking to almost everyone who will use the new system or has experience with similar systems.

New Section 1 Page 14

talking to almost everyone who will use the new system or has experience with similar systems.

Define requirements
The analyst defines system requirements using information gathered from users and
documents. These requirements include functional requirements (the functions the system
must perform) and nonfunctional requirements (user-interface formats, reliability, performance,
and security).

Prioritize Requirements
Users often request additional functions that are desirable but not essential. Prioritizing is
necessary because resources are limited, and the scope of the system must be justified to
determine the number, composition, and order of project iterations, with high-priority
requirements often addressed early.

Develop User-Interface Dialogs

Abstract models like use cases and activity diagrams can be difficult for users to interpret and
validate. Analysts can create user interfaces through abstract models, storyboards, or
prototypes on actual devices.

Evaluate Requirements with Users

Analysts usually use an iterative process in which they elicit user input to model requirements,
return to the user for additional input or validation, and then work alone to incorporate the new
input and refine the models.

What Are Requirements?

System requirements- all the activities the new system must perform or support and the
constraints that the new system must meet. (functional and nonfunctional)

Functional requirements -the activities the system must perform to support the users’ work

Nonfunctional requirements -required system characteristics other than the activities it must
perform or support

The F in FURPS is equivalent to the functional requirements defined previously. The remaining
categories (URPS) describe nonfunctional requirements
F -functional
U -usability : operational characteristics related to users, such as the user interface, related
work procedures, online help, and documentation
R -reliability :describe the dependability of a system, how often a system exhibits such
behaviours as service outages and incorrect processing and how it detects and recovers from
those problem
P -performance :describe operational characteristics related to measures of workload, such as
throughput and response time
S -security :describe how access to the application will be controlled and how data will be
protected during storage and transmission

FURPS+ is an extension of FURPS that adds additional categories, including

New Section 1 Page 15

FURPS+ is an extension of FURPS that adds additional categories, including
design constraints as well as implementation, system interface, physical,
and supportability requirements
• Design constraints describe restrictions to which the hardware and
software must adhere. For example, a cell phone application might
need to run on the Android operating system, use no more than 30
MB of flash storage
• Implementation requirements describe constraints such as required
programming languages and tools, documentation method and level
of detail, and a specific communication protocol for distributed
components.
• Physical requirements describe such characteristics of hardware as
size, weight, power consumption, and operating conditions.
• Supportability requirements describe how a system is installed,
configured, monitored, and updated.

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

Internal stakeholders -are those within the organization who interact with
the system or have a significant interest in its operation or success.

External stakeholders -persons outside the organization’s control and

influence who interact with the system or have a significant interest in its
operation or success.

Operational stakeholders -are those who regularly interact with a system

in the course of their jobs or lives.

Executive stakeholders -are those who do not interact directly with the system, but who either use
information produced by the system or have a significant financial or other interest in its operation
and success.

Client -a person or group that provides the funding for the system development project

Information-Gathering Techniques

New Section 1 Page 16

 • 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

Interview Users and Other Stakeholders

• Prepare detailed questions
Question Themes:

Question Types:
open-ended questions- “How do you do this function?”— encourage discussion and
explanation.
closed-ended questions- “How many forms a day do you process?”—are used to get specific
facts.
• 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

Distribute and Collect Questionnaires

Questionnaires enable analysts to collect information from a large number of stakeholders.

Review Inputs, Outputs, and Procedures

Two sources of information about inputs, outputs, and procedures.
External industry-wide professional organizations and other companies are a potential source of
important information.
Internal Reviewing internal documents and procedures to get a preliminary understanding of the
processes

Models and Modeling

Model -is a representation or abstraction of some aspect of the system being built

New Section 1 Page 17

textual models -text-based system models such as memos, reports, narratives, and lists
:event list and use case descriptions
graphical models -system models that use pictures and other graphical elements to create a diagram
mathematical models -system models that describes requirements numerically or as mathematical
expressions
Unified Modeling Language (UML) -standard set of information system model constructs and
notations defined by the Object Management Group

Documenting Workflows with Activity Diagrams

workflow -sequence of work steps that completely handle one business transaction or customer
request
activity diagram -UML diagram that describes user (or system) activities, the person or component
that completes each activity, and the sequential flow of these activities
synchronization bar -an activity diagram component that either splits a control path into multiple
concurrent paths or recombines concurrent paths
swimlane -an activity diagram component that divides the workflow activities into groups showing
which agent performs which activity

New Section 1 Page 18

C3: Identifying User Stories and Use Cases
user story -one short sentence in the everyday language of the end user that states what a user does
as part of his or her work
acceptance criteria -features that must be present in the final system for the user to be satisfied
use case -an activity that the system performs in response to a request by a user

“As a <role played>, I want to<goal or desire> so that<reason or benefit> .”

New Section 1 Page 19

Use Cases and the User Goal Technique

user goal technique -a technique to identify use cases by determining what specific goals or
objectives must be completed by the system for the user

Identifying use cases with the user goal technique

1. Identify all the potential users for the new system.

2. Classify the potential users in terms of their functional role (e.g., shipping, marketing, sales).
3. Further classify potential users by organizational level (e.g., operational, management, executive)
4. Interview each type of user to determine the specific goals they will have when using the new
system. Start with goals they currently have and then get them to imagine innovative functions they
think would add value. Encourage them to state each goal in the imperative verb-noun form, such as
Add customer, Update order, and Produce month-end report.
5. Create a list of preliminary use cases organized by type of user.
6. Look for duplicates with similar use case names and resolve inconsistencies.
7. Identify where different types of users need the same use cases.
8. Review the completed list with each type of user and then with interested stakeholders.

New Section 1 Page 20

Use Cases and Event Decomposition

event decomposition technique -identify use cases by determining the business events to which the
system must respond “What business events occur that will require the system to respond?”
elementary business processes (EBP) -is performed by one person in one place in response to a
business event, adds measurable business value, and leaves the system and its data in a stable and
consistent state.
event -something that occurs at a specific time and place, can be precisely identified, and must be
remembered by the system
actor -an external agent; a person, group or external system that interacts with the system by
supplying or receiving data

Types of Events
external event -an event that occurs outside the system, usually initiated by an external agent

temporal event -an event that occurs as a result of reaching a point in time

State/internal event -an event that occurs when something happens inside the system that triggers
some process often occur as a consequence of external events.

If the sale of a product results in an adjustment to an inventory record, and the inventory in stock
drops below a reorder point, it is necessary to reorder. The state event might be named “Reorder
point reached.”

system controls -which are checks or safety procedures put in place to protect the integrity of the
system and data
:logging on to a system
:backing up the data every day

perfect technology assumption -a system runs under perfect operating and technological conditions

Steps in the Event Decomposition Technique

New Section 1 Page 21

Steps in the Event Decomposition Technique
To summarize, the event decomposition technique for identifying use cases includes these steps:
1. Consider the external events in the system environment that require a response from the system
by using the external event checklist
2. For each external event, identify and name the use case that the system requires.
3. Consider the temporal events that require a response from the system by using the temporal
event checklist
4. For each temporal event, identify and name the use case that the system requires and then
establish the point of time that will trigger the use case.
5. Consider the state events that the system might respond to, particularly if it is a real-time system
in which devices or internal state changes trigger use cases.
6. For each state event, identify and name the use case that the system requires and then define the
state change.
7. When events and use cases are defined, check to see if they are required as part of analysis by
using the perfect technology assumption. Do not include events that involve such system controls as
login, logout, change password, and backup or restore the database, as these are put in as system
controls.

brief use case description -an often one-sentence description that provides a quick overview of a
use case

use case diagram -the UML model used to illustrate use cases and their relationships to actors
automation boundary -the boundary between the computerized portion of the application and the
users who operate the application but are part of the total system

New Section 1 Page 22

C4: Domain Modeling
problem domain -the specific area (domain) of the user’s business need that is within the scope of
the new system For example, some information systems need to store information about customers
and products, so it is important for the analyst to identify all the important information about them.

brainstorming technique -used to identify problem domain classes in which developers work with
users to identify classes by thinking about different types of things they use in their work

New Section 1 Page 23

noun technique -used to identify things in the problem domain by finding and classifying the nouns
in a dialog or description

attributes -descriptive pieces of information about things or objects

association -a term, in UML, that describes a naturally occurring relationship between specific things
relationship -a term, in database management, that describes a naturally occurring association
between specific things

The Entity-Relationship Diagram

Diagram consisting of data entities, their attributes, and their relationships

New Section 1 Page 24

The Domain Model Class Diagram

Generalization/Specialization Relationships

A generalization/specialization relationship is used to structure or rank these things from the more
general to the more special.

Generalizations are judgments that group similar types of things. For example, there are several
types of motor vehicles: cars, trucks, and tractors. All motor vehicles share certain general
characteristics, so a motor vehicle is a more general class.

Specializations are judgments that group different types of things. For example, special types of cars
include sports cars, sedans, and sport utility vehicles. These types of cars are similar in some ways
yet different in other ways.

Each class of things in the hierarchy might have a more general class above it, called a superclass.
At the same time, a class might have a more specialized class below it, called a subclass.

New Section 1 Page 25

Inheritance -allows subclasses to share characteristics of their superclass.

An OnlineSale actually has eight attributes (six from Sale and two additional).
An InStoreSale has nine attributes, and a TelephoneSale has eight attributes.

Whole-Part Relationships
Whole-part relationships -are used to show an association between one class and other classes that
are parts of that class.
Two types of whole part relationships:
Aggregation -which the component parts also exist as individual objects apart from the aggregate
: A keyboard is not a special type of computer; it is part of a computer, but it is also
something separate. Uses empty diamond symbol representing aggregation
Composition -which the component parts cannot exist as individual objects apart from the total
composition
: A house that is made up of bathrooms, bedrooms, stairwell, and so forth. The
bathrooms or bedrooms never exist apart from the house; therefore, this whole-part
relationship is a composition and uses solid diamond connectors.

The State Machine Diagram—Identifying Object Behaviour

state -a condition during an object’s life when it satisfies some criterion, performs some action, or
waits for an event

New Section 1 Page 26

waits for an event

transition -the movement of an object from one state to another state

state machine diagram -a diagram showing the life of an object in states and transitions

pseudostate -the starting point of a state machine diagram, indicated by a black dot

destination state -for a particular transition, the state to which an object moves after the
completion of a transition

origin state -for a particular transition, the original state of an object from which the transition
occurs

The transition label consists of the following syntax with three components:
transition-name (parameters, …) [guard-condition] / action-expression

action-expressions -descriptions of the activities performed as part of a transition

guard-condition -a true/false test to see whether a transition can fire. For the transition to fire, the
guard must be true

New Section 1 Page 27

C5: Use Case Modeling
Use Case Descriptions

use case description -a textual model that lists and describes the processing details for a use case

New Section 1 Page 28

preconditions -conditions that must be true before a use case begins
postconditions -what must be true upon the successful completion of a use case

Activity Diagrams for Use Cases

New Section 1 Page 29

The System Sequence Diagram—Identifying Inputs and Outputs

system sequence diagram (SSD) -a diagram showing the sequence of messages between an actor
and the automated part of the system during a use case or scenario

SSD Notation

lifeline, or object lifeline the vertical line under an object on a sequence diagram to show the
passage of time for the object1

In a System Sequence Diagram (SSD), a stick figure represents an actor (a person or role) interacting
with the system by entering input and receiving output. The box labeled "
" represents the entire automated system as an individual object, not a class of similar objects. This
object is unnamed, indicated by a colon before the underlined class name.
Below the actor and
are vertical dashed lines called lifelines, extending during the use case to show the sequence of
interactions. Arrows between lifelines represent messages sent by the actor, with the arrow's origin
and destination indicating the sender and receiver, respectively. Messages are labeled to describe
their purpose and any input data, following a verb-noun syntax. In SSDs, messages act like
commands invoked on the destination object, showing the interaction sequence from top to
bottom.

New Section 1 Page 30

The clerk sends a request (message) to the system to find an item, with input data in parentheses
identifying the item. This request is shown as a solid line with an arrow. The system's response is
indicated by a dashed line with an arrow, representing returned data. The response format includes
only the data being returned, such as item information (description, price, quantity). Additional
details can be provided in a note attached to the diagram or in supporting documentation.
Messages may also be sent repeatedly in a loop.

loop frame -notation on a sequence diagram showing repeating messages

true/false condition -part of a message between objects that is evaluated prior to transmission to
determine whether the message can be sent

New Section 1 Page 31

To add an item to an order multiple times, the process is shown within a "loop frame," a
large rectangle indicating repeated operations. Inside the frame, a smaller rectangle
describes the loop condition. An alternative notation uses square brackets for a
true/false condition and an asterisk (*) to indicate repetition. The true/false condition
controls the loop and is placed directly on the message, simplifying the notation.

The complete message notation is:

true/falsecondition return-value := message-name (parameter-list)

Key components:
• An asterisk (*) indicates repetition.
• Brackets indicate a true/false condition, determining if the message is sent.
• Message-name describes the requested service (verb-noun format).
• Parameter-list shows data passed with the message (parentheses for initiating
messages).
• Return-value describes data returned from the destination to the source object,
using :=.
This notation can be concise for simple repeating messages, while the loop frame is
more precise for complex conditions.

New Section 1 Page 32

Developing a System Sequence Diagram (SSD)
An SSD helps document the details of a use case or scenario, explicitly identifying the
inputs and outputs involved. It is developed based on a detailed use case description
or activity diagram, which outlines the flow of activities but not the specific inputs
and outputs. Here’s a summary of the steps involved in developing an SSD:
1. Identify Input Messages: Locate points in the activity diagram where a
workflow arrow crosses from an external actor to the system, indicating
required input data.
2. Describe Messages: Use message notation to describe messages from the
external actor to the system. Name the message to reflect the requested
service (in verb-noun form) and include input parameters based on the class
diagram’s attributes. For example, in creating a customer account, messages
might include createNewCustomer, enterAddress, and enterCreditCard, each
with relevant data parameters.
3. Add Special Conditions: Include any iteration and true/false conditions for
input messages. For example, enterAddress might be repeated for each
address, indicated by an asterisk symbol.
4. Add Output Return Messages: Identify return messages using dashed arrows
or as return values on the same line as the message. The activity diagram can
provide clues, but not all transitions from the system to an external actor
indicate an output.
In summary, an SSD provides a clear, structured way to document the interaction
between external actors and the system, detailing the inputs and outputs for each
use case scenario.

New Section 1 Page 33

Use Cases and CRUD
The CRUD technique (Create, Read, Update, Delete) is essential for validating use
cases, ensuring that all necessary operations for data maintenance are covered.
Here’s a summary of the process:
1. Identify Data Types: Start by identifying the types of data stored in the system,
modeled as domain classes (e.g., Customer, Product).
2. Verify Use Cases: Ensure that there are use cases for creating,
reading/reporting, updating, and deleting instances of each data type. This
helps cross-check and fill gaps in the identified use cases.
3. Refine Use Cases: Use CRUD to verify and refine use cases rather than blindly
adding CRUD functions. For instance, if a use case already creates a customer
account, there's no need for a separate "Create customer" use case.
4. Cross-Application Clarity: In integrated systems, clarify which application is
responsible for CRUD operations to avoid overlaps and ensure clear
boundaries. For example, the RMO CSMS uses but does not create or delete
product data managed by another application.
5. Summarize and Match Use Cases: Match use cases with domain classes,
indicating their role (C, R, U, D) to ensure comprehensive coverage. For
instance, if the "Create customer account" use case creates customer and
account data, it should be marked with "C" for those classes.
Steps for CRUD Validation:
1. Identify all domain classes involved.
2. Verify use cases for creating, reading/reporting, updating, and deleting
instances for each domain class.
3. Add overlooked use cases and identify relevant stakeholders.
4. Clarify responsibilities among integrated applications regarding data
maintenance and usage.

New Section 1 Page 34

Integrating Requirements Models
To fully specify system functional requirements, analysts use various diagrams to
model the details of use cases. The iterative approach means only constructing
necessary diagrams for each iteration. Here are the key points summarized:
1. Iterative Approach:
○ Develop only required diagrams for each iteration.
○ Complete use case diagrams to understand the total system scope.
○ Detailed modeling is not needed for all use cases in every iteration.
2. Domain Model Class Diagram:
○ Should be nearly complete early in the project to outline the system
scope.
○ Necessary for identifying all domain classes and designing the database.
○ Refine and implement many classes in later iterations.
3. Diagram Interdependence:
○ Construction of one diagram often depends on information from
another.
○ Development of new diagrams helps refine and correct previous ones.
○ Detailed diagrams are crucial for understanding user requirements.
4. Primary Models:
○ Use case diagram and domain model class diagram are foundational.
○ Develop these two diagrams comprehensively.
5. Detailed Descriptions:
○ Narrative formats or activity diagrams provide internal documentation of
use cases.
○ Must support the use case diagram and align with the domain model
class diagram.
○ Crucial for developing system sequence diagrams.
6. Consistency and Quality:
○ Ensure detailed descriptions, activity diagrams, and system sequence
diagrams are consistent.
○ Understanding relationships among models enhances the quality of the
system design.

New Section 1 Page 35

Object-orientated Requirements Models
Thursday, 20 June 2024 19:49

Use case diagram

Domain model class diagram

Use case descriptions

New Section 1 Page 36

Activity diagrams

New Section 1 Page 37

State machine diagrams

System sequence diagrams (SSDs)

New Section 1 Page 38

Relationships among object-oriented requirements models

Design class diagram

New Section 1 Page 39

Essentials of Systems Design
Thursday, 20 June 2024 20:19

C6: Foundations for Systems Design

Analysis, Design, and Implementation

1. Definitions:
○ Systems Design: Activities detailing how an information system will be
implemented.
○ Systems Analysis: Activities specifying what the new system should
achieve.
2. Sequential Process:
○ Analysis precedes Design:
▪ Understand and specify the final product's goals before designing.
▪ For a banner/poster, analysis includes the message, physical size, and
display location.
▪ For a commercial aircraft, analysis involves requirements like
capacity, fuel consumption, range, speed, reliability, maintenance
costs, longevity, and construction cost.
▪ Complex requirements in aircraft design lead to interdependent
design tasks.
3. Design to Implementation Link:
○ Direct Link: Design plans guide the implementation process.
○ Banner/Poster: Simple design with drawings and specifications on a few
pages.
○ Aircraft: Complex design with thousands of documents detailing every part.
○ Both designs provide sufficient information for building the final product.
4. Documentation:
○ Essential for coordinating multiple people’s work.
○ Critical for communication with downstream activities.
5. Key Points:
○ Analysis: Starting point for design.
○ Design: Starting point for implementation.
○ Both analysis and design need thorough documentation to ensure
successful implementation.

New Section 1 Page 40

Design Models
1. Transition from Analysis to Design:
○ Design activities build upon documents and models created during analysis.
○ Analysis outputs serve as inputs for design, ensuring continuity and clarity in
system development.
2. Concurrent Activities in Iterative Projects:
○ In iterative approaches, analysis and design often overlap.
○ Initial focus in each iteration is on identifying and specifying requirements
(analysis), followed by designing solutions.
3. Purpose of Analysis:
○ Analysts create models during analysis to understand business processes and
information requirements.
○ Analysis involves decomposition of complex problems into manageable parts
and requires substantial user involvement for accuracy and verification.
4. Design Activities:
○ Designers transform requirements models from analysis into detailed system
models.
○ Design focuses more on technical aspects and involves less user interaction,
relying more on collaboration with other system professionals.
5. Output of Design:
○ Design activities produce diagrams and documents that model various
aspects of the solution system.
○ These outputs provide a blueprint for development and implementation
phases.
6. Formality in Project Execution:
○ Formal projects demand well-developed design documents reviewed in
structured meetings.
○ Informal projects, typical in Agile development, may have less formal design
processes, but design activities are still crucial for clarity and coherence.
7. Importance of Thoughtful Design:
○ Thoughtful design prevents issues like errors, patches, and unreliable
systems.
○ Rushed coding without adequate design, known as "cowboy coding," leads
to inefficiencies and maintenance challenges.
8. Major Design Models:
Figure 6-2 illustrates key models used in both analysis and design phases.

New Section 1 Page 41

 ○ Figure 6-2 illustrates key models used in both analysis and design phases.
○ Examples include class diagrams and state machine diagrams, which serve
roles in both stages of development.

Design Activities
1. Definition of Systems Design:
○ Systems design specifies how a system will operate within a specific
technology environment.
○ It involves adding detailed specifications beyond what was defined in
systems analysis.
2. Interconnectedness of Design:
○ Design activities are interdependent; each part of the solution influences
and is influenced by other parts.
○ For instance, database design impacts application components, software
structures, and user interfaces.
3. Parallel Activities:
○ Systems design tasks are typically conducted concurrently.
○ This parallelism ensures that all aspects of the system are considered
and integrated effectively.
4. Influence of Technology Environment:
The technology environment significantly shapes design decisions.

New Section 1 Page 42

 ○ The technology environment significantly shapes design decisions.
○ It dictates how system functions are distributed among components and
how these components communicate across networks.
5. Iterative Approach in SDLC:
○ In iterative SDLC approaches, major design decisions are initially made in
the first or second iteration.
○ Subsequent iterations revisit and refine these decisions based on
evolving requirements and feedback.
6. Continuous Refinement:
○ Design is an iterative process itself, evolving as understanding deepens
and more detailed requirements are clarified.
○ Refinements in design ensure alignment with user needs and
technological capabilities.

Describe the Environment"

Key Elements of the Environment:
1. External Systems:
○ Interactions with external systems are identified during analysis.
○ Detailed information about message formats, addresses, protocols,
security measures, and error handling is required for designing
application components.
2. Technology Architecture:
○ Defined as the set of computing hardware, network infrastructure, and
system software used by an organization.
○ Examples include servers, desktops, mobile devices, network topologies,
communication protocols, operating systems, and system software like
DBMS and web servers.
○ Forms the foundation on which application components are deployed
and interact.
○ Designers must ensure that the system components can effectively
communicate and integrate with the existing technology architecture.
Role of Environment in Design:
• Precedence in Design Activities:
○ "Describe the Environment" is the first activity in design, emphasizing its
critical role.
Unlike other design activities that involve creating new components,

New Section 1 Page 43

 ○ Unlike other design activities that involve creating new components,
describing the environment acknowledges the constraints imposed by
external systems and existing technology architecture.
• Control and Adaptation:
○ Designers have little control over external systems and existing
technology architecture.
○ System components must adapt to fit within the constraints and
capabilities of the environment.
• Impact on System Design:
○ Understanding the environment guides decisions on how system
components will interact, communicate, and integrate.
○ Ensures compatibility and efficiency in the deployment of application
components.
Conclusion:
• Designing a system involves understanding and accommodating the external
systems and technology architecture within which it will operate.
• Detailed descriptions of external systems and technology architecture precede
the design of specific application components.
• This approach ensures that the system design aligns with organizational
infrastructure and operational requirements, facilitating effective deployment
and integration.

Design the Application Components"

Definition and Complexity of Application Components:
• An application component is a distinct unit of software that performs specific
tasks.
• Components vary greatly in size, from small methods or scripts to large
subsystems containing thousands of lines of code or entire websites.
• They are defined differently across programming languages and can include
functions, classes, methods, scripts, or entire subsystems.
Considerations in Designing Application Components:
1. Programming Languages:
○ Traditional languages use functions or procedures; object-oriented
languages use classes and methods; scripting languages embed within
other components.
○ Variations in naming, size, and relationships exist across different
programming languages and toolkits.
2. Build or Buy Decision:
○ Organizations decide whether to develop components in-house, reuse
existing components, purchase off-the-shelf solutions, or integrate
external services through APIs (e.g., Google Maps, FedEx tracking).
○ This decision impacts how components are grouped, packaged, and
integrated within the system.
3. Subsystem Design:
○ Initial step involves dividing the software into subsystems or modules.
○ Considerations include database infrastructure, multilayer architecture
separating user interface, business logic, and database processing.
○ Alignment with the organization's technology architecture (e.g.,
Microsoft .NET or Oracle DBMS) influences design decisions.
4. Relationship with Software Classes:
○ Application component design precedes detailed design of software
classes and methods.
○ Components are further specified into classes and methods, which
define the internal workings of each component.
5. Output of Application Component Design:

New Section 1 Page 44

 5. Output of Application Component Design:
○ Produces models (diagrams) and supporting documents detailing the
structure, interactions, and functionality of each component.
○ Models include subsystem diagrams, component diagrams, and other
relevant documentation.
Conclusion:
• Designing application components is a critical activity that precedes the
detailed design of software classes and methods.
• It involves decisions on how functions are grouped, packaged, and integrated
within the system architecture.
• The outcome is a set of detailed models and documents that guide the
implementation of each component, ensuring alignment with organizational
needs and technology infrastructure.

"Design the User Interface"

Importance and Scope of User Interface Design:
• The user interface (UI) is the primary interaction point between users and a
system, directly influencing user satisfaction and system success.
• A high-quality UI can be a competitive advantage, enhancing productivity and
morale, while a poor UI can lead to errors and inefficiencies, impacting
business outcomes.
Evolution of User Interface Requirements:
• Historically, UI design focused on simplifying information presentation and
reducing user input on desktop monitors.
• Modern UI design is complex due to diverse devices (phones, tablets, multi-
monitor displays), technologies (multitouch, voice recognition), and user
contexts (office, conference room, travel).
Challenges in UI Design:
• UI design is no longer about creating a single interface but addressing multiple
interfaces tailored to different devices and contexts.
• Understanding user needs, job tasks, and physical environments is crucial
during both analysis and design phases of UI development.
Methods and Tools in UI Design:
• UI design involves various models and tools such as mock-ups, storyboards,

New Section 1 Page 45

 • UI design involves various models and tools such as mock-ups, storyboards,
graphical layouts, and prototyping with screen-modeling tools.
• System sequence diagrams from analysis phases are often expanded and
reused in UI design to map user interactions and system responses.
Conclusion:
• Designing user interfaces is a multifaceted process that integrates analysis and
design activities.
• Successful UI design requires understanding diverse user needs, leveraging
evolving technologies, and deploying tailored interfaces across multiple
devices and contexts.
• Effective UI design enhances usability, productivity, and user satisfaction,
contributing significantly to the success of a system or business.

"Design the Database"

Role and Importance of Database Design:
• Database design is integral to information systems, as it defines the structure
and organization of data that underpins system functionality.
• The data model, initially created during systems analysis as the domain model
class diagram, serves as the foundation for designing the database
implementation model.
Database Structure and Decisions:
• The first step in database design involves determining its structure, which can
range from traditional computer files to complex relational databases with
numerous interconnected tables.
• Decisions must be made regarding centralized versus distributed databases,
often incorporating both files and relational databases within the same
system.
Technical Considerations in Database Design:
• Database designers must address a variety of technical issues:
○ Performance: Designing for optimal response times and tuning database
performance.
○ Security: Implementing security measures and encryption to ensure data
integrity.
Scalability: Considering replication, partitioning, and distribution across

New Section 1 Page 46

 ○ Scalability: Considering replication, partitioning, and distribution across
multiple servers or sites to meet scalability requirements.
○ Integration: Ensuring seamless integration with existing databases,
possibly involving different database management systems (DBMSs).
Complexities and Expertise in Database Design:
• Database design often requires specialized skills in database architecture,
security, performance optimization, and physical configuration.
• Given the global connectivity of systems today, databases may need to be
replicated or partitioned across different geographic locations, necessitating
careful planning and execution.
Conclusion:
• Designing a database involves translating the conceptual data model into a
robust, efficient, and secure database implementation.
• It requires careful consideration of technical requirements, performance
objectives, security needs, and integration with existing systems to ensure the
database meets the functional and operational goals of the information
system.

"Design the Software Classes and Methods"

Expanded in Chapters 12, 13, and 14
Objective of the Activity:
• The primary goal of designing software classes and methods is to provide
detailed blueprints for software developers. These blueprints ensure that
programmers have clear instructions on how to implement the functionality of
the system.
Extension of Analysis Models:
• During this design phase, analysis models such as class diagrams, system
sequence diagrams, and state-machine diagrams are extended and refined to
incorporate software-specific details.
• New models, such as sequence diagrams, are created to depict interactions
between software components and the flow of operations within the system.
Key Deliverables:
• Design Class Diagrams: These diagrams illustrate the structure of software
classes, their attributes, methods, and relationships. They serve as a visual
guide for developers and help in organizing the software architecture.
• Sequence Diagrams: These depict interactions between objects in a sequential
order, illustrating how methods and functions are called and executed during
specific scenarios.
• State-Machine Diagrams: Used to model the behavior of objects over time,
showing different states and transitions based on events or actions.
Importance of Detailed Design:
• The detailed design ensures that all aspects of the system's behavior and
functionality are well-defined before implementation begins.
• It helps in identifying potential issues early, enabling adjustments to be made
during the design phase rather than during or after coding.

New Section 1 Page 47

 during the design phase rather than during or after coding.
Preparation for Implementation:
• The outcome of this design activity is a set of detailed models and diagrams
that serve as a foundation for writing code.
• These models guide programmers in writing and testing software methods,
ensuring that the final implementation meets the system requirements and
design specifications.

"System Controls and Security"

Purpose of Controls and Security:
• Controls and security measures in modern systems aim to mitigate various
risks, including incorrect data input, unauthorized access, and malicious
attacks. These measures ensure the confidentiality, integrity, and availability of
system resources.
Types of Controls:
• Organization-wide Controls: Examples include identity management systems
and access controls that are standardized across an organization. These
controls ensure that authorized users have appropriate access to data and
applications.
• System-Specific Controls: These controls are tailored to the specific
requirements and risks of individual systems. For instance, a payroll-processing
system implements controls to verify data input validity and restrict access
based on user roles.
Integration into Design Activities:
• Controls and security measures are not standalone activities but are integral
components embedded within various design activities:
○ User Interface Design: Security considerations such as authentication
and authorization mechanisms are implemented to ensure secure user
interactions.
Database Design: Security controls, such as encryption and access

New Section 1 Page 48

 ○ Database Design: Security controls, such as encryption and access
control mechanisms, are designed into the database structure and
methods.
○ Application Component Design: Each component incorporates controls
to enforce security policies and prevent unauthorized access.
Further Considerations:
• Understanding the role of controls and security within system design prepares
designers to implement robust protection mechanisms tailored to both
organizational and system-specific needs.
• By embedding security measures into all design activities, systems can achieve
resilience and reliability in safeguarding sensitive information and maintaining
operational continuity.

"Designing Integrity Controls"

Purpose of Controls: Controls are essential mechanisms and procedures integrated
into systems to safeguard both the system itself and the information it manages.
They ensure the integrity, confidentiality, and availability of data and system
resources.
Integrity Controls:
• Function: Integral to both application programs and the supporting database.
• Purpose: Ensuring the accuracy and reliability of data inputs and outputs.
• Actions: Rejecting invalid data inputs, preventing unauthorized data outputs,
and protecting against accidental or malicious tampering.
Security Controls:
• Scope: Generally encompass operating system and network protections.
• Function: Focus on broader system security, including access controls,
firewalls, encryption, and intrusion detection/prevention systems.
• Objective: Safeguarding system resources from unauthorized access, breaches,
and cyber threats.
Integration of Controls:
• System Design: Controls, especially integrity controls, are integrated
throughout various components of the system design process.
• Application Programs: Implemented within software to validate data integrity
and ensure accurate processing.
• Database: Incorporated to enforce data integrity rules and prevent
unauthorized modifications.

New Section 1 Page 49

Input Controls
Purpose of Input Controls: Input controls are mechanisms implemented within a
system to prevent invalid or erroneous data from entering the system. They ensure
data integrity and accuracy by validating inputs before they are processed further.
Types of Input Controls:
1. Value Limit Controls:
○ Purpose: Ensure numeric data inputs fall within acceptable ranges.
○ Example: Restricting sales amounts to a reasonable range (e.g., rejecting
negative values or amounts exceeding $10,000).
2. Completeness Controls:
○ Purpose: Ensure all required data values for an object or transaction are
present.
○ Example: Verifying that a shipping address contains all necessary
information for successful delivery.
3. Data Validation Controls:
○ Purpose: Ensure data entered matches predefined rules or formats.
○ Example: Validating that entered letter grades (e.g., A, B, C) match a
predefined list of acceptable grades.
4. Field Combination Controls:
○ Purpose: Review combinations of data inputs to ensure logical
correctness.
○ Example: Verifying that an insurance policy's application date precedes
or matches its effective coverage date.

Output Controls
Purpose of Output Controls: Output controls ensure that system outputs are
accurate, secure, and delivered to the correct destination. They prevent
unauthorized access to sensitive information and maintain the integrity of output
data in various forms, such as printed reports or electronic displays.
Types of Output Controls:
1. Physical Access Controls to Printers:
○ Purpose: Restrict access to printers and printed outputs to authorized
personnel only.
○ Implementation: Printers should be located in secure areas, accessible
only to individuals with proper clearance.
2. Discarded Output Control:

New Section 1 Page 50

 2. Discarded Output Control:
○ Purpose: Ensure sensitive printed outputs are securely disposed of to
prevent unauthorized access.
○ Implementation: Printed documents containing sensitive data should be
shredded or destroyed rather than discarded normally.
3. Access Controls to Display or Print Programs:
○ Purpose: Restrict access to programs that display or print sensitive
information.
○ Implementation: Access controls use mechanisms like usernames,
passwords, or access devices to limit who can view or print sensitive
outputs.
4. Formatting and Labeling of Printed Outputs:
○ Purpose: Ensure completeness and accuracy of printed reports.
○ Implementation: Include control data such as date/time stamps,
pagination, control totals, and "end of report" markers to verify the
integrity of printed outputs.
5. Labeling of Electronic Outputs:
○ Purpose: Identify and validate electronic outputs to ensure authenticity
and integrity.
○ Implementation: Electronic outputs should include internal labels or
tags specifying source, content, relevant dates, and may include
checksums or control totals to detect data loss or tampering.

Redundancy, Backup, and Recovery

Purpose and Importance: Redundancy, backup, and recovery procedures are
essential components of system management designed to safeguard software and
data from hardware failures, natural disasters, and malicious attacks. These practices
ensure continuity of operations and minimize downtime in the event of disruptions.
Redundancy:
• Definition: Redundancy involves deploying multiple servers, databases, or sites
that host copies of critical resources.
• Purpose: Provides fault tolerance by ensuring that if one server or site fails,
others are still operational.
• Implementation: Updates are synchronized across redundant servers or sites
to maintain data consistency and operational continuity.
Backup Procedures:
• Definition: Backup involves creating copies of file systems, databases, or other
critical data to removable storage media or off-site storage locations.
• Purpose: Protects against data loss due to hardware failures, software errors,
or disasters.
• Implementation: Backups are scheduled regularly (e.g., daily, weekly) during
low-demand periods to minimize impact on system performance.
Recovery Procedures:
• Definition: Recovery involves restoring data and software from backup copies
to resume operations after a disruption or data loss event.
• Purpose: Ensures that systems can be restored to a functional state quickly
and efficiently.
• Implementation: Recovery operations may take minutes to hours depending
on the size of the data and the nature of the failure. Off-site backups are
accessed to replicate data to operational servers for resumed access.

Access Controls
Access controls are crucial mechanisms implemented within information systems to
manage and restrict user access to resources such as servers, files, applications, and
databases. These controls help ensure data confidentiality, integrity, and availability
by limiting access to authorized personnel only.

New Section 1 Page 51

by limiting access to authorized personnel only.
Key Components of Access Control Systems:
1. Authentication:
○ Definition: Authentication verifies the identity of users attempting to
access sensitive resources.
○ Methods: Includes usernames/passwords, smart cards, biometric
methods (fingerprint/retinal scans, voice recognition), and multifactor
authentication combining multiple methods for enhanced security.
○ Purpose: Ensures that only legitimate users with verified identities can
access the system.
2. Access Control List (ACL):
○ Definition: ACL is a list associated with a resource that specifies which
users or user groups are permitted to access the resource and the type
of access allowed (e.g., read, write, execute).
○ Role: Controls access permissions based on predefined rules, preventing
unauthorized users from accessing resources.
3. Authorization:
○ Definition: Authorization determines what actions an authenticated user
is permitted to perform on a specific resource based on the ACL.
○ Role: Ensures that authenticated users are granted appropriate access
rights according to their roles and responsibilities within the
organization.
Effective Design Considerations:
• User Categorization: Designers categorize system users into unauthorized,
registered, and privileged users based on their roles and responsibilities.
○ Unauthorized Users: Individuals who are explicitly denied access to any
part of the system, including former employees and external threats
such as hackers.
○ Registered Users: Authorized personnel allowed varying levels of access
based on their job roles and specific permissions (e.g., read-only, update
certain data fields).
○ Privileged Users: Individuals with elevated access rights, including
system programmers, administrators, and operators, who have access to
sensitive resources like source code and system configurations.

C7: Defining the System Architecture

Networks, the Internet, and the World Wide Web

This section explores the foundational concepts of computer networks, the Internet, and the
World Wide Web (WWW), emphasizing their significance in modern computing and information
systems:
1. Computer Networks:
○ A computer network comprises hardware, software, and transmission media
enabling devices to communicate and share resources.
○ Networks vary from small-scale setups in homes or offices to global networks
connecting countries and continents.
2. The Internet:
○ The Internet is a vast network of interconnected networks, facilitating global
information exchange.
○ It acts as a global highway for data transmission, supported by high-capacity
backbone networks owned by governments or telecommunications companies.
3. Local Area Networks (LANs):
○ LANs span smaller areas like homes, offices, or single buildings, connecting servers
and devices wirelessly or via cables.
○ LANs typically connect to the Internet through larger networks covering broader
geographic areas.

New Section 1 Page 52

 geographic areas.
4. World Wide Web (WWW):
○ The WWW is a subset of the Internet consisting of interconnected resources
accessed via URLs.
○ It encompasses various content types such as static web pages, multimedia, emails,
and interactive services like e-commerce and online gaming.
5. Key Distinctions:
○ Internet vs. Web: The Internet refers to the infrastructure enabling global
connectivity, while the Web denotes the collection of accessible resources and
services.
○ Internet Backbone Networks: Provide high-speed, reliable connectivity essential for
transmitting vast amounts of data globally.
6. Uniform Resource Locator (URL):
• URLs are addresses identifying web resources, comprising three main components:
the protocol, the domain name and the resource path.

C8: Designing the User Interface

Understanding the User Experience and the User Interface

Definitions
1. User Experience (UX):
○ Definition: UX encompasses all interactions a person has with a product or
service, including software applications. It includes actions, responses,
perceptions, and feelings during and before usage.
○ Significance: UX is crucial in system design as it influences how users perceive
and interact with the application. Designers must consider the overall user
journey to enhance satisfaction and usability.
2. User Interface (UI):
○ Definition: UI refers to the set of inputs and outputs through which users interact
directly with an application.
○ Role: It is the visible part of the system that users engage with directly, making it
a critical aspect of the overall user experience.
○ Variability: UI design varies based on factors such as user characteristics, device
type, and interface purpose. It ranges from internal tools optimized for
operational efficiency to customer-facing applications tailored for mobile devices.

Types of Output Reports in Information Systems

Detailed Reports: Detailed reports provide specific information on business transactions,
typically presenting detailed data for each transaction or entity. For example, a detailed
report might list all overdue accounts with specific details about each account, such as

New Section 1 Page 53

 report might list all overdue accounts with specific details about each account, such as
customer name, overdue amount, and due date.
Summary Reports: Summary reports aggregate data to provide a condensed overview of
periodic activities or operations. They often include totals or averages for a set period. For
instance, a weekly summary of sales transactions might include the total dollar amount of
sales for that week, enabling managers to track overall departmental or divisional
performance.
Exception Reports: Exception reports highlight transactions or results that deviate from
predefined norms or thresholds. They focus on anomalies or outliers in business operations.
For example, a manufacturing organization might generate an exception report listing parts
that fail quality control tests more frequently than a specified threshold (e.g., 0.2% failure
rate).
Executive Reports: Executive reports are designed for senior management to provide a high-
level view of organizational performance and health. These reports typically include
summarized information from various activities within the company and may include
comparisons with industry benchmarks or historical data. They help executives assess overall
organizational performance and make strategic decisions.
Usage and Examples:
• Detailed Report Example: A confirmation of an online order displayed to a customer,
detailing items purchased, quantities, prices, and shipping information.
• Summary Report Example: A weekly summary report showing total sales revenue
across different product categories.
• Exception Report Example: A report listing inventory items with stock levels below a
specified minimum threshold.
• Executive Report Example: A quarterly report for senior management summarizing
financial performance metrics like revenue, profitability, and market share.

Usability in System Design

Definition and Importance: Usability in system design refers to how easy it is for
users to learn and use a system effectively.

Affordance in User Interface Design

Definition and Concept: Affordance in user interface design refers to the quality of a
visual element that suggests its functionality or purpose.

Visibility in User Interface Design

Definition and Concept: Visibility in user interface (UI) design refers to the quality of
making controls and elements readily perceivable to users. It involves ensuring that
users can easily locate and interact with interface components, and that these
components provide immediate feedback upon interaction.

C9: Designing the Database

Roles of Data Administrator (DA) and Database

Administrator (DBA)
New Section 1 Page 54
Administrator (DBA)
Data Administrator (DA):
• Responsibilities:
○ Data Standards: Establishing and enforcing naming conventions,
definition standards, data types, and validation rules to ensure
consistency and integrity across the organization's data assets.
○ Data Use: Defining ownership of data, accessibility permissions, and
confidentiality requirements to safeguard sensitive information.
○ Data Quality: Implementing measures such as validation rules,
completeness checks, currency maintenance, consistency checks, and
relevancy assessments to ensure high-quality data.
Database Administrator (DBA):
• Responsibilities:
○ Database Management: Configuring and maintaining the database
management system (DBMS) to optimize performance and ensure
compatibility with the organization’s overall IT architecture.
○ Security Management: Implementing and managing user
authentication, access controls, and security measures to protect the
database against unauthorized access and attacks.
○ Performance Monitoring: Monitoring database performance, identifying
bottlenecks, and optimizing database operations to ensure high levels of
efficiency and responsiveness.
○ Backup and Recovery: Establishing backup strategies and recovery
procedures to safeguard data integrity and ensure rapid restoration in
the event of system failures or disasters.

New Section 1 Page 55

System Development and Project Management
Thursday, 20 June 2024 22:14

C10: Approaches to System Development

The System Development Life Cycle (SDLC) Approaches

Predictive Approach to SDLC:
• Characteristics:
○ Assumes that the development project can be fully planned and
organized before implementation begins.
○ Suitable for projects where requirements are well-understood, and
the system can be defined clearly from the outset.
○ Example: Converting an existing client/server system to a modern
Web-based system with a smartphone app. Since requirements are
clear and understood, the project can be meticulously planned and
executed according to specifications.
Adaptive Approach to SDLC:
• Characteristics:
○ Used when system requirements and/or users' needs are not well-
understood initially.
○ Acknowledges that complete planning upfront may not be feasible,
and requirements might evolve during development.
○ Developers remain flexible, adapting the project based on feedback
and evolving understanding of requirements.
○ Example: The Tradeshow System described previously utilized this
approach, where initial development work helped refine
requirements and adapt the system as understanding deepened.
Key Differences:
• Planning and Flexibility:
○ Predictive SDLC emphasizes thorough planning and adherence to
predefined specifications.
○ Adaptive SDLC prioritizes flexibility and responsiveness to evolving
requirements and user feedback.
Application:
• Choosing the Right Approach:
○ Organizations select the SDLC approach based on the clarity of project
requirements and the extent to which they can be predefined.
○ Predictive SDLC suits projects with well-defined requirements,
ensuring efficient execution.
○ Adaptive SDLC suits projects where requirements are likely to change,
allowing for iterative development and continuous adaptation.

Traditional Predictive Approaches to the SDLC

Overview: Traditional predictive approaches to the System Development Life Cycle
(SDLC) involve a sequential progression through defined phases aimed at ensuring
thorough planning and execution of an information system project.

New Section 1 Page 56

thorough planning and execution of an information system project.
Phases of Traditional Predictive SDLC:
1. Project Initiation:
○ Activities include problem identification, feasibility study, and securing
approval for the project.
2. Project Planning:
○ Involves detailed planning, organizing resources, and scheduling
activities for the project.
3. Analysis:
○ Focuses on understanding and documenting detailed requirements of
the system based on business needs.
4. Design:
○ Configures and structures system components based on previously
gathered requirements.
5. Implementation:
○ Involves actual programming, testing, and integration of the system
components.
6. Deployment:
○ Installing the system and making it operational in the production
environment.
Support Phase:
• Activities involved in maintaining and upgrading the system post-deployment,
ensuring ongoing functionality and usability.

Waterfall Model:
• Characteristics:
○ Represents the most rigid form of predictive SDLC.
○ Phases proceed sequentially, with each phase considered complete
before moving to the next.
○ Emphasizes thorough planning and documentation at each stage.
• Challenges:
○ Potential issues include difficulty in accommodating changes once a
phase is completed, and the risk of errors or omissions that become
evident in later stages.

Modified Waterfall Models:

• Characteristics:
○ Allow for overlapping phases to address interdependencies and
evolving requirements.
Retain the structured approach of the waterfall model while

New Section 1 Page 57

 ○ Retain the structured approach of the waterfall model while
incorporating flexibility.
○ Example activities overlapping include analysis during design to refine
requirements or adjust design based on analysis findings.

C10: Project Planning and Project Management

The Role of the Project Manager

Overview: Project management involves organizing and directing efforts to achieve
a planned outcome within specified constraints of time, budget, and resources. It
encompasses planning, monitoring, and controlling activities throughout the
project lifecycle.
Key Responsibilities of a Project Manager:
1. Project Planning and Execution:
○ Develops project plans detailing activities, deliverables, and resource
requirements.
○ Manages project schedules, ensuring tasks are completed on time and
within budget.
○ Recruits, trains, and assigns tasks to team members.
○ Assesses risks associated with the project and implements mitigation
strategies.
2. Internal Management:
○ Acts as the central point of control for the project team.
○ Establishes team structure and fosters a productive work environment.
○ Monitors and controls project progress, ensuring milestones and
deliverables are achieved.
3. External Communication and Stakeholder Management:
○ Represents the project team to external stakeholders, including clients
and sponsors.
○ Reports project status and progress to stakeholders regularly.
○ Collaborates closely with clients to understand and address their needs
and expectations.
○ Identifies resource requirements and secures necessary resources for
the project.
4. Client and Stakeholder Interaction:
○ Works with clients who fund the project and approve its milestones.
○ Engages with users to gather detailed requirements and ensure system
functionality meets their needs.
○ Communicates effectively with oversight committees and executive
stakeholders to align project goals with organizational strategies.

New Section 1 Page 58

New Section 1 Page 59
Advanced Design and Deployment Concepts
Thursday, 20 June 2024 22:35

C:14 Deploying the New System

Testing
Overview: Testing is a critical part of the implementation and deployment phases of
software development. It involves examining components, subsystems, or entire
systems to assess their operational characteristics and identify defects.
Process and Requirements:
• Specifications: Testing begins with well-defined specifications for both
functional (what the system should do) and nonfunctional (how well the system
performs) requirements.
• Expected Characteristics: Test developers derive precise definitions of expected
operational characteristics from these requirements.
• Testing Cycle: Developers design and build software, execute its functions, and
analyse results. If deficiencies or defects are found, the team revisits earlier
implementation or deployment stages to rectify them.
Types of Testing:
• Core Processes: Different types of tests correspond to specific core processes,
detecting defects and measuring operational characteristics (see Figure 14-2 for
details).
• Test Cases: These are formal descriptions specifying:
○ The starting state or condition.
○ Events to which the software must respond.
○ The expected response or ending state.
• Test Data: Represents the starting and ending states and events, ensuring
thorough testing of normal and exceptional processing situations.
Challenges and Automation:
• Complexity: Testing involves preparing comprehensive test cases and data,
which is labour-intensive.
• Automation: Automated tools based on mathematical techniques help
generate complete test cases, covering all instructions and scenarios effectively.

Unit Testing
Overview: Unit testing is the earliest and most fundamental level of testing in
software development. It involves testing individual components, methods, or
classes in isolation to ensure they function correctly before integration into larger
systems.

New Section 1 Page 60

systems.
Definition and Scope:
• Definition of Unit: In modern object-oriented development, a unit can be as
small as an individual method or as large as a class or a small set of integrated
classes (component).
• Purpose: The primary goal of unit testing is to validate each unit of software in
isolation to detect and fix errors early in the development process. This
ensures that the units are error-free before they are integrated into larger
software systems.
Characteristics of Unit Testing:
1. Isolation: Unit tests are conducted in isolation from other components to
ensure that any failures or errors are attributable solely to the unit being
tested.
2. Developer Responsibility: Unit tests are typically created and executed by the
developers who wrote the code. This approach ensures quick iteration and
debugging.
3. Efficiency: Unit tests should be quick to execute and not require extensive
resources. They should validate functionality rapidly without setting up
complex testing environments.
Challenges and Strategies:
• Dependency Management: Testing in isolation can be challenging if the unit
relies on external components or data. Stubs or mock objects are often used to
simulate dependencies.
• Test Data: Both valid and invalid test data should be used to ensure robustness
and error handling in the unit.
• Automation: Tools and frameworks exist for automated unit testing, which
streamline the process and support frequent testing during iterative
development.
Benefits:
• Enhanced Quality: Unit testing helps identify defects early, reducing the cost
and effort of fixing them later in the development lifecycle.
• Developer Productivity: It promotes cleaner, more maintainable code by
enforcing accountability and ensuring that code meets specified requirements
from the outset.
• Integration Support: Well-tested units integrate smoothly into larger systems,
contributing to overall system reliability and stability.

Integration Testing
Overview: Integration testing is a phase in software development where individual
units (such as classes or components) are combined and tested as a group. Its
primary goal is to evaluate the interaction and interfaces between these units and to
verify the functionality of the integrated software system.
Key Objectives:
• Interface Testing: Ensures that the interfaces between components work
correctly. This includes checking for compatibility issues, parameter
mismatches, and unexpected interactions between component states.
• Functional Behavior Testing: Validates the expected behavior of the
integrated software system as a whole, ensuring that it performs as intended
when units are combined.
Types of Integration Testing:
• Small-Scale Integration: Initially involves integrating units developed by
individual programmers into larger components.
• Large-Scale Integration: Extends to integrating components developed by
different teams or across different parts of the organization, increasing
complexity and requiring more coordinated testing efforts.
Process and Activities:

New Section 1 Page 61

Process and Activities:
1. Building Components for Integration: Components are combined to form
larger integrated units, sometimes necessitating specific builds for testing
purposes.
2. Creating Test Data: Preparation of complex test data that reflects real-world
scenarios and ensures comprehensive testing coverage.
3. Conducting Integration Tests: Execution of integration tests to verify the
interactions and functionalities of the integrated components. This includes
assigning responsibilities for test execution and resource management.
4. Evaluating Results: Analysis of test outcomes to identify discrepancies or
failures, involving collaboration among developers to resolve issues.
5. Logging and Tracking: Maintaining error logs to document and track identified
issues throughout the testing process, ensuring they are properly addressed.
Challenges and Considerations:
• Complexity Management: As integration testing progresses, managing the
complexity of interactions between diverse components becomes crucial.
• Data Coordination: Coordination among teams and developers is essential for
creating, formatting, and updating test data to ensure comprehensive testing
coverage.
• Resource Allocation: Allocation of resources, including personnel and testing
environments, to facilitate effective and efficient integration testing.
Benefits:
• Error Detection: Identifies defects and issues that may arise from interactions
between components, which may not be apparent during unit testing.
• Quality Assurance: Ensures that the integrated software system meets
functional requirements and performs reliably under varied conditions.
• Risk Mitigation: Reduces the risk of critical failures by uncovering and
addressing integration issues early in the development lifecycle.

System, Performance, and Stress Testing

System Testing: System testing is a comprehensive integration test of an entire
system or independent subsystem to verify its behavior and functionality. It typically
occurs during the deployment phase of the SDLC and focuses on both functional and
nonfunctional requirements. System testing often tests nonfunctional aspects such as
response time and throughput. It marks a transition from integration testing, covering
larger components or the entire system less frequently.
Key Points:
• Scope and Timing: System tests encompass the entire system or large
subsystems, conducted less frequently compared to integration tests which are
more frequent and target smaller component groups.
• Types of Tests: Includes functional and nonfunctional tests to ensure both the
correctness and performance of the system. Examples include regression
testing, acceptance testing, and load testing.
Build and Smoke Tests:
• Purpose: A subset of system testing, build and smoke tests are conducted
frequently (daily or several times a week).
• Process: Ensures that newly integrated software components or changes do not
cause obvious malfunctions ("smokes"). Provides rapid feedback on integration
issues.
Performance Testing: Performance testing evaluates whether a system or subsystem
meets specific time-based performance criteria, such as response time and
throughput requirements. It is crucial for ensuring that the system performs
acceptably under expected loads and stress conditions.
Key Aspects:
• Complexity: Involves testing multiple layers of software, subsystems, hardware,

New Section 1 Page 62

 • Complexity: Involves testing multiple layers of software, subsystems, hardware,
and network infrastructure.
• Test Data: Requires a comprehensive suite of test data to simulate normal and
maximum operational loads.
• Failure Diagnosis and Correction: Identifies bottlenecks and underperforming
components, followed by tuning or reconfiguration of software, hardware, or
network settings to optimize performance.

User Acceptance Testing (UAT)

Definition and Purpose: User Acceptance Testing (UAT) is a crucial phase in software
testing that evaluates whether a system meets user requirements and business
needs. It serves as the final confirmation that the system is ready for deployment.
Key Aspects of UAT:
• Comprehensive Testing: UAT tests the system against all user scenarios and
business processes to ensure it fulfills functional and nonfunctional
requirements.
• Formality: In some cases, UAT is a formal milestone requiring completion and
sign-off by the client or stakeholders. It may be outlined in contractual
agreements such as requests for proposal (RFPs) or procurement contracts.
• Integration in Agile: In Agile projects, UAT may be less formal and integrated
throughout development, with continuous feedback from users influencing
system refinement.
• Importance: Skipping or minimizing UAT due to project delays or time
constraints can lead to serious issues post-deployment. Proper UAT ensures
that the system performs as expected and reduces the likelihood of major
problems.
Challenges and Risks:
• Time Constraints: Pressure to meet deadlines may lead to rushed or
incomplete UAT, risking system quality.
• Deployment Readiness: UAT verifies readiness for deployment; skipping it
increases the chances of deployment failures and subsequent costly fixes.
• Lessons from Failures: Examples like the Affordable Care Act website
underscore the consequences of inadequate UAT, including delayed launches
and contract terminations.
Recommendations:
• Further Study: Extensive resources are available on planning, preparing, and
executing successful UAT. Proper planning ensures thorough testing and
validation of the system.
• Execution Phases: UAT involves planning, preparation (defining test cases,
scenarios, and acceptance criteria), and execution (conducting tests,
documenting results, and obtaining sign-off).

New Section 1 Page 63