Systems Analysis and Design

KCA UNIVERSITY ICT NOTES

Foundation level
Section 2
SYSTEMS ANALYSIS AND DESIGN

DEFINITION OF A SYSTEM
It is an organized, purposeful structure regarded as a whole and consisting of interrelated and interdependent elements. These elements continually influence one another (directly or indirectly) to maintain their activity and the existence of the system in order to achieve the goal of the system.
General systems theory (GST) employs systems approach to enhance the understanding of complex phenomenon and problems. GST focuses on the system’s structure instead of on the system’s function. It proposes that complex systems share some basic organizing principles irrespective of their purposes, and that these principles can be modelled mathematically.

SYSTEM CHARACTERISTICS

1. Environment: It refers to the surrounding of the system or the factors which have direct or indirect influence on the system for example the environment of a business system comprises of customers and suppliers
   Factoring: It states that a system is divided into a number of subsystems for efficient allocation of resources
   Inputs and outputs: A system must have a mechanism for accepting inputs from its environment and must be able to transform the inputs into meaningful output to support the process of decision making
2. Equifinality: This property of the system states that the goals of system can be achieved using different methods for example an organization may maximize its profit through advertising or through the manufacturing of unique products
3. Control: All systems must have a control mechanism to monitor their activities and to prevent unauthorized manipulation of their resources.
4. Synergy (wholism): It states that subsystems produce better results when they work together than when they work as different units.
5. Decoupling: This characteristic states that the tightly bonded subsystems must be separated to enhance efficiency and quality of decision making
6. Sub-optimization: This characteristic states that the subsystems may attempt to achieve their goals at the expense of the organizations goals
7. Feedback: Feedback provides the control in a dynamic system. Positive feedback is routine in nature that encourages the performance of the system. Negative feedback is informational in nature that provides the controller with information for action
8. Boundary: A system should be defined its boundaries. Boundaries are the limits that identify its components, processes, and interrelationship when it interfaces with another system. Each system has boundaries that determine its sphere of influence and control.

KASNEB PAST PAPER QUESTIONS
Dec 2021 Q3c&d, 5b, May 2017 Q5b
May 2016 Q5a & Q6b

CLASSIFICATION OF SYSTEMS

Man-made and Natural systems

• Natural systems are attributed to God or nature
• Man-made systems are artificial systems which are attributed to man. Man-made information systems are divided into three types:

1. 1. Formal Information System: It is based on the flow of information in the form of memos, instructions, etc., from top level to lower levels of management.
   2. Informal Information System: This is employee based system which solves the day to day work related problems.
   3. Computer Based System: This system is directly dependent on the computer for managing business applications. For example, automatic library system, railway reservation system, banking system, etc.

Physical and Abstract systems

• A physical system has tangible elements or components
• Abstract systems are conceptual entities which can only be visualized but cannot be touched

Probabilistic (stochastic) and deterministic systems

Probabilistic systems are those whose behavior or outcome cannot be accurately predicted Deterministic systems behave in a defined manner

Open and closed systems
An open system freely interacts with its environment
A closed system does not freely interact with its environment and exist in concept only.

Open loop and closed loop systems
Open loop systems do not have an internal control and feedback mechanism hence they cannot compare inputs and outputs. They comprise of an input, processing and output units
Closed loop systems have internal control and feedback mechanisms i.e. they can compare inputs with outputs to verify whether there are any deviations. They comprise of an input, processing, control and output units

Open loop system diagram

Closed loop system diagram

Permanent and Temporary Systems
Permanent System persists for long time. For example, business policies. Temporary System is made for specified time and after that they are demolished.

KASNEB PAST PAPER QUESTIONS
May 2016 Q6c

SYSTEMS DEVELOPMENT

Systems development is the activity of creating or modifying existing business systems. It refers to all aspects of the process from identifying the problem to its implementation.

Reasons for Initiating Systems Development

Systems development initiatives arise from all levels of an organization both planned as well as well unplanned. Solid planning and managerial involvement helps to ensure that initiatives support broader organizational goals.

1. Desire to exploit new opportunities: An organization may develop a new system or modify an existing one as a result of new technology or changes in user requirements.
2. Increasing competition: When competitors increase in the market, it is important for organizations to develop new systems or modify the existing ones in order to have a competitive edge.
3. Desire to make more effective use of information: Most organizations have information which is not put into use hence the strategic level managers may decide to initiate new systems.
4. Organizational growth: Most organizations have grown from the time they were initiated. As a result of this growth management must initiate the development of new systems e.g. an organization may develop a computerized payroll system to pay its employees as a result of an increase in the number of employees.
5. Merger: When organizations merge, new systems must be developed or initiated in order to cater for the new goals or objectives.
6. Change in market or external environment: The market is always the determinant as far as business systems survival is concerned hence if an organization manufactures products, it must be able to change its methods depending on market changes.
7. Current Information system does not meet the objectives of users

 

REQUIREMENTS ELICITATION

Requirements Elicitation is an active effort to extract project-related information from all relevant stakeholders. The objective is to clearly define the business or project objectives. Requirements elicitation uses various analytics and techniques that allow for complete, concise and clear requirements to be gathered.

Discussing requirements is one of the first and most important stages of software development. The scope, budget, and time estimation for a project fully depend on how complete, clear, and relevant the requirements are.

In software development, requirements describe the solution to be developed, including its functions, interfaces, design, and user experience. They’re usually formulated the client or stakeholders — people who are involved in or affected the project and therefore are interested in its success.

Types of requirements

1. Business requirements describe why a project is needed and how the company will benefit from it.
2. Stakeholder requirements capture the needs and expectations of stakeholders.
3. Solution requirements contain technical demands. They can be functional (describing what the system should do) and non-functional (describing the qualities the system should have).
4. Transition requirements define actions to be taken to transfer an organization from its current state to the desired state.

Why requirements should be elicited.
Gathering accurate requirements is an important task carried out a business analyst (BA). A single missed or unclear requirement may lead to scope creep, budget overruns, creation of irrelevant functionality or an increase in the required development hours. To avoid this, a BA starts working on requirements at the very beginning of the project. Once all the requirements are gathered, the business analyst starts eliciting them. Let’s find out why this process is important and how it’s done.

Benefits of Requirements elicitation

1. Establishes the precise scope of work and the budget: Clear, prioritized, and approved requirements allow a development team to accurately plan and estimate a project. That means we can provide the client with a realistic budget and release dates.
2. Avoids confusion during development: A shared understanding of what should be done, when, and how to finish a project greatly speeds up and streamlines communication. Productive elicitation helps to avoid numerous meetings that should have been emails during development.
3. Adds business value: To develop a product that will facilitate a customer’s business activities, it’s important to discuss
   both what should be done the development team and why. With that understanding, the team can create a solution that meets all the client’s needs.
4. Reveals hidden and assumed requirements: Stakeholders always know their market and business needs the best. That’s why stakeholders may find some requirements too obvious to discuss. But developers need to know each aspect of the solution, and a BA helps them figure out and specify such requirements.
5. Allows for developing only relevant functionality: When discussing requirements, business analysts use their knowledge of the development team to improve the initial requirements. They help clients cast off inefficient features and choose the best possible technologies.

 

PROCESS OF REQUIREMENTS ELICITATION

The three main stages are preparing for elicitation, eliciting software requirements and finalizing the elicitation

Preparing for elicitation.

It involves the following stages

1. Collecting the documentation
The business analysts or system developers will collect the documentation they need including

a) A description of the organization: business rules, structure, legal and regulatory requirements
b) Details of the project: solution analysis results, reports, or requirements prepared other business analysts, technical and end user documentation of the existing system, manuals, instructions, tutorials for users and employees
c) Marketing materials: market research, competitor analysis, materials used to promote the solution.

2. Analyzing stakeholder roles.

During this analysis, a BA defines all stakeholders affected the project and decides which of them should be involved in elicitation. This stage is necessary to speed up the elicitation process, engage only relevant stakeholders in the discussion, and keep everyone affected future changes informed.

3. Preparation of use case and process flow diagrams
A use case diagram is a graphical representation of a relationship between an actor (a user, application, or system) and a solution. User flow diagrams help you visualize all possible interactions with a solution and choose the one that best suits the client’s needs.
A process flow diagram is a chart that visualizes the processes happening inside a solution. It shows participants in the process, steps in the process, decision points, events, and their triggers.
Use case and process flow diagrams allow for improving a stakeholder’s understanding of those scenarios and possible issues.

4. Preparing stakeholders for elicitation.
At this stage, BAs make sure all participants understand the goal and process of elicitation. Preparation includes:

• • Choosing the most appropriate means of communication with stakeholders (email, in-person meetings, etc.)
  • Scheduling periodic meetings if necessary
  • Defining which information is needed from stakeholders.

Eliciting software requirements

Elicitation happens during a series of meetings with various stakeholders. During these meetings, a business analyst has several tasks including

1. Defining requirements for the development team and stakeholders. Stakeholders of the same project may understand the requirements differently. It’s up to the BA to help stakeholders articulate their needs and make sure everyone agrees.
2. Managing the elicitation. Discussions of requirements may turn in unexpected directions, especially if they involve multiple stakeholders. Business analysts should control and guide these discussions so all questions are answered.
3. Documenting discussions. During elicitation, a BA takes notes of the progress stakeholders make to improve the initial requirements after the meeting.
4. Following up with participants. Follow-ups help to structure the topics discussed and the outcome of each elicitation session.

Finalizing the elicitation

Once elicitation is done, a business analyst goes through the requirements to make sure that each of these questions is answered for each requirement:

• Why? — Why should the requirement be implemented, what problem does it solve, and what benefits does it provide?
• What? — What is the exact meaning of the requirement, what are the business rules, and what are the compliance or other requirements?
• How? — What are the possible ways to implement the requirement and what are the possible obstacles (outdated or insecure technologies, network limitations, etc.)?
• When? — How urgent is the requirement and how should it be prioritized?

Requirements elicitation Methods

There are a number of requirements elicitation methods. Few of them are listed below –

1. Interviews
2. Brainstorming Sessions
3. Facilitated Application Specification Technique (FAST)
4. 4. Quality Function Deployment (QFD)

The success of an elicitation technique used depends on the maturity of the analyst, developers, users, and the customer involved.

1. Interviews
Objective of conducting an interview is to understand the customer’s expectations from the software.
It is impossible to interview every stakeholder hence representatives from groups are selected based on their expertise and credibility.

Interviews maybe be open-ended or structured.

1. In open-ended interviews there is no pre-set agenda. Context free questions may be asked to understand the problem.
2. In structured interview, agenda of fairly open questions is prepared. Sometimes a proper questionnaire is designed for the interview.
2. Brainstorming Sessions
• It is a group technique
• It is intended to generate lots of new ideas hence providing a platform to share views
• A highly trained facilitator is required to handle group bias and group conflicts.
• Every idea is documented so that everyone can see it.
• Finally, a document is prepared which consists of the list of requirements and their priority if possible.
3. Facilitated Application Specification Technique
It’s objective is to bridge the expectation gap – difference between what the developers think they are supposed to build and what customers think they are going to get.

A team oriented approach is developed for requirements gathering. Each attendee is asked to make a list of objects that are-

1. Part of the environment that surrounds the system
2. Produced the system
3. Used the system
Each participant prepares his/her list, different lists are then combined, redundant entries are eliminated, team is divided into smaller sub-teams to develop mini-specifications and finally a draft of specifications is written down using all the inputs from the meeting.
4. Quality Function Deployment
In this technique customer satisfaction is of prime concern, hence it emphasizes on the requirements which are valuable to the customer. 3 types of requirements are identified namely
• Normal requirements.
The objective and goals of the proposed software are discussed with the customer. Example – normal requirements for a result management system may be entry of marks, calculation of results, etc
• Expected requirements.
These requirements are so obvious that the customer need not explicitly state them. Example – protection from unauthorized access.
• Exciting requirements.
It includes features that are beyond customer’s expectations and prove to be very satisfying when present. Example – when unauthorized access is detected, it should backup and shutdown all processes.

The major steps involved in this procedure are –

1. Identify all the stakeholders, eg. Users, developers, customers etc
2. List out all requirements from customer.
3. A value indicating degree of importance is assigned to each requirement.

4. In the end the final list of requirements is categorized as –
• It is possible to achieve
• It should be deferred and the reason for it
• It is impossible to achieve and should be dropped off

Question
Discuss the Challenges of requirements elicitation.

SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)

The System Development Life Cycle framework provides a sequence of activities for system designers and developers to follow. It consists of a set of steps or phases in which each phase of the SDLC uses the results of the previous one.
The systems development process is called systems development life cycle because the activities associated with it are ongoing. As each system phase is built, the project has timeliness and deadlines until the system is installed and accepted. If the system needs significant improvement beyond the scope of maintenance and if it needs to be replaced because of new technology then a new project will be initiated and the cycle will start over again.

A systems development lifecycle (SDLC) has three primary objectives namely to

1. Ensure that high quality systems are delivered
2. Provide strong management controls over the projects
3. Maximize the productivity of the systems staff.

GENERAL SDLC PHASES

1. Definition of system specifications
2. Feasibility study
3. System analysis
4. System design
5. System implementation

SDLC APPROACHES

1. Traditional SDLC
2. Prototyping
3. Rapid application development (RAD)

TRADITIONAL SDLC (WATERFALL MODEL)

This method results in systems development over a long period of time. Traditional SDLC is usually a function or process driven approach i.e. it requires the analyst to follow a sequence of stages/ phases during the development and implementation of new information systems. The SDLC phases include

1. Planning

This is the first phase in the systems development process. It identifies whether or not there is the need for a new system to achieve a business’s strategic objectives. This is a preliminary plan (or a feasibility study) for a company’s business initiative to acquire the resources to build on an infrastructure to modify or improve a service. The company might be trying to meet or exceed expectations for their employees, customers and stakeholders too. The purpose of this step is to find out the scope of the problem and determine solutions.
Resources, costs, time, benefits and other items should be considered at this stage.

2. Systems Analysis and Requirements

The second phase is where businesses will work on the source of their problem or the need for a change. In the event of a problem, possible solutions are submitted and analyzed to identify the best fit for the ultimate goal(s) of the project. This is where teams consider the functional requirements of the project or solution. It is also where system analysis takes place—or analyzing the needs of the end users to ensure the new system can meet their expectations. Systems analysis is vital in determining what a business’s needs are, as well as how they can be met, who will be responsible for individual pieces of the project, and what sort of timeline should be expected.

There are several tools businesses can use that are specific to the second phase. They include:

• CASE (Computer Aided Systems/Software Engineering)
• Requirements gathering
• Structured analysis

3. Systems Design

The third phase describes, in detail, the necessary specifications, features and operations that will satisfy the functional requirements of the proposed system which will be in place. This is the step for end users to discuss and determine their specific business information needs for the proposed system. It is during this phase that they will consider the essential components (hardware and/or software) structure (networking capabilities), processing and procedures for the system to accomplish its objectives.

4. Development

The fourth phase is when the real work begins. In particular, when a programmer, network engineer and/or database developer are brought on to do the major work on the project. This work includes using a flow chart to ensure that the process of the system is properly organized. The development phase marks the end of the initial section of the process. This phase signifies the start of production. The development stage is also characterized instillation and change. Focusing on training can be a huge benefit during this phase.

5. Integration and Testing

The fifth phase involves systems integration and system testing (of programs and procedures). It is carried out a Quality Assurance (QA) professional to determine if the proposed design meets the initial set of business goals. Testing may be repeated, specifically to check for errors, bugs and interoperability. This testing will be performed until the end user finds it acceptable. Another part of this phase is verification and validation, both of which will help ensure the program’s successful completion.

6. Implementation

The sixth phase is when the majority of the code for the program is written. This phase involves the actual installation of the newly-developed system. This step puts the project into production moving the data and components from the old system and placing them in the new system via a direct, parallel, phased or pilot changeover. Both system analysts and end-users should now see the realization of the project that has implemented changes.

7. Operations and Maintenance

The seventh and final phase involves maintenance and regular required updates. This step is when end users can fine-tune the system, if they wish, to boost performance, add new capabilities or meet additional user requirements.

The Waterfall model is suitable for the following situations

1. Requirements are well-documented and well-defined.
2. The definition of the product is consistent.
3. Technology is well-understood and unchanging.
4. There are no unclear criteria.
5. The product is supported many resources with the necessary knowledge.
6. The project is not long.
7. The speed of project delivery is not a priority.
8. The client does not want to be included in the development process but wants to be informed at the start and given a working product at the conclusion.

KASNEB PAST PAPER QUESTIONS

Dec 2021 Q5c, 6b Nov 2018 Q1b, 2b, 4d May 2018 Q2b
Dec 2017 Q2d
Sept 2015 Q5d
Dec 2014 Q6c & Q7 May 2014 Q7c
June 2013 Q2b
Dec 2012 Q3a
May 2012 Q7b
Nov 2011 Q2b
Dec 2009 Q6

PROTOTYPING

In software development, a prototype is a working model of a product or information system, usually built for demonstration purposes or as part of the development process. In the systems development life cycle (SDLC), the prototyping model is a basic version of the system that is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed.

Prototyping is used

a) When the application area is not well defined
b) When the users requirements are not clearly known.
c) When the organization is not familiar with the technology required to develop the system.
d) When the communication between the analyst and the users is not very clear.
e) When there is need to save on system development cost and time.
f) When there is need to involve users in systems development process with an aim of reducing user resistance.

Prototyping stages

The following are the stages of prototyping:-

Identification of user/system requirements
This is done system development team either through observation or going through the system specification.

Development of the Initial prototype

The developer writes the relevant codes which are interpreted the computers into machine code. The initial prototype is developed based on the use requirements.

Presentation of the prototype to the user
This done to enable users evaluate the model using the actual data. The users then identify errors and make relevant suggestions and recommendations.

Revision of the prototype
The prototype is changed to meet the user requirements based on the suggestions and recommendation. The analyst then presents the revised prototype to user for further evaluation before the final system is produced.

Documentation of the prototype

Based on the revised prototype the analyst produces a documentation of the prototype which is meant to guide during system development.

Role of Users in Prototyping

1. They help the developers to quickly and easily understand the user requirement before the development of the final version of the system.
2. Users give suggestions and recommendations about the areas to be improved the systems developers.
3. When the users are involved, they are able to understand the type of system being developed hence minimize their resistance towards the prototype.
4. The users are able to advise the management on the benefits of the prototype hence its approval.

Advantages of Prototyping

1. They allow information systems to be developed quickly.
2. Saves on the system development efforts since it doesn’t involve many stages like the traditional SDLC methods.
3. Prototyping enables systems to be developed cheaply.
4. Since users are involved, it helps to reduce user resistance towards the systems which are implemented.
5. Since users learn how to use the system during its development, the need for training is minimized.

Disadvantages of Prototyping

1. It may be impossible to change the prototype to meet the non-functional requirements.
2. The prototype may be inadequately documented.
3. The systems structure may be degraded through the changes made during development.
4. Prototyping tools are inefficient and occupy more computer memory resulting in longer execution time.

KASNEB PAST PAPER QUESTIONS
May 2017 Q3c, Sept 2015 Q2b

 

RAPID APPLICATION DEVELOPMENT (RAD)

RAD is a methodology that enables organizations to develop strategically important systems faster while reducing development costs and maintaining quality. This is achieved using a series of proven application development techniques, within a well-defined methodology.

It is an approach to building computer systems which combines Computer-Assisted Software Engineering (CASE) tools and techniques, user-driven prototyping, and stringent project delivery time limits into a potent, tested, reliable formula for high quality and productivity. It raises the quality of finished systems while reducing the time it takes to build them.

The RAD lifecycle
The structure of the RAD lifecycle is thus designed to ensure that developers build the systems that the users really need. This lifecycle, through the following four stages, includes all of the activities and tasks required to scope and define business requirements and design, develop, and implement the application system that supports those requirements.

Requirements Planning
Also known as the Concept Definition Stage, this stage defines the business functions and data subject areas that the system will support and determines the system’s scope.

User Design.
Also known as the Functional Design Stage, this stage uses workshops to model the system’s data and processes and to build a working prototype of critical system components.

Construction
Also known as the Development Stage, this stage completes the construction of the physical application system, builds the conversion system, and develops user aids and implementation work plans.

Implementation
Also known as the Deployment stage, this stage includes final user testing and training, data conversion, and the implementation of the application system

Note: If the requirements are obvious, the first two Stages may be combined

Advantages of RAD

1. Ensures fast development of systems without compromising their quality
2. t highlights most of the risks in system development hence the final product will be very qualitative.
3. RAD limits the exposure of the system to forces of change.
4. Since the users are involved in the development process the possibility of user resistance is minimal.
5. Greatly reduced manual coding because of wizards, code generators and code reuse
6. Greater flexibility because developers can redesign almost at will

Disadvantages of RAD

1. It requires sufficient human resources which may not be available.
2. In many cases RAD does not work independently which may compromise the objectives of the organization
3. The documentation of systems designed using RAD requires highly competent personnel. This may be expensive to organization.
4. Requirements may not converge because the interests of customers and developers may diverge from one iteration to the next.

Question
Differentiate between RAD and Traditional SDLC

KASNEB PAST PAPER QUESTIONS
Nov 2018 Q6b
May 2015 Q1d
Dec 2013 Q5c
Dec 2010 Q2