ANALYSIS
Higher SDD
LESSON AIMS
By the end of this lesson all pupils will be able to:
❏ Describe the function of the analysis phase
❏ Define the purpose, scope and boundaries of a piece of
software
❏ Detail the Functional and User requirements of a piece of
software
❏ Design solutions to problems detailing the data flow and any
major refinements
EXTRACTING THE CLIENTS NEEDS
● This is sometimes called requirements elicitation. This can be difficult as
the client may not be fully aware of what might (or might not) be possible,
and the software analyst will probably not be fully familiar with the client's
business operations.
● The analyst might begin by interviewing the client company management
and other staff as well as using questionnaires to get a clear statement of
what needs to be done.
● The analyst might also make observation notes of the operations and
workflow of the client's business to find out what actually happens in the
workplace.
DOCUMENTING THE CLIENTS NEEDS
● The end result of the requirements elicitation process is a formally written statement of what
the client wants the design team to do - the software specification.
● The completed specification (agreed on by both parties) is the basis of a legally binding
contract which can be used by either party to resolve possible disputes in the future.
● This document is also the basis for everything the software company goes on to make, so it is
extremely important to get it right.
● Communication is NOT just a single event. There may be several meetings which have to take
place between client(s) and the analyst.
● The need to clarify what has been said, and what is meant by what has been said, will often
arise.This is an iterative process and is repeated until both sides are in complete agreement.
COMMUNICATING REQUIREMENTS TO THE DEVELOPMENT TEAM
● The development team may identify technical and financial limitations which may require
compromises and revisions to the original requirements.
● Ideas may be too costly to implement. The client's hardware infrastructure may not be able to
support aspects of the proposed software or certain
● The software specification therefore must clearly state the scope, boundaries and
functional requirements of the proposed development.
● The (revised) specification is returned to the client to verify. This iterative process aims to
ensure that the client will end up with a product that is fit for purpose, cost effective and
delivered on time.
PURPOSE, SCOPE AND BOUNDARIES
When performing the analysis stage of a project there are 3 things
that have to be considered first
❏ Purpose
❏ Scope
❏ Boundaries
PURPOSE, SCOPE AND BOUNDARIES
Purpose: a general description of the purpose of the software.
Scope: a list of the deliverables that the project will hand over to the client
and/or end-user, eg design, completed program, test plan, test results and
evaluation report. It can also include any time limits for the project.
Boundaries: the limits that help to define what is in the project and what is not.
It can also clarify any assumptions made by the software developers regarding
the client’s requirements.
FUNCTIONAL REQUIREMENTS
Once the purpose scope and boundaries have been established then the
requirements have to be established
Functional requirements: the features and functions that must be delivered
by the system in terms of inputs, processes and outputs.
EXAMPLE: PURPOSE
A teacher needs a program that will process the prelim and coursework marks
for their class of 20 pupils which are held in a file.They will also need to find the
percentages and the best performing student.
So the purpose is:
To take 20 pupil names, their prelim marks and their assignment marks from a
file. Calculate the percentage, and then find and display the name and percentage
of the pupil with the highest percentage.
EXAMPLE: SCOPE
Scope: list of the deliverables that the project will hand over to the client and/or
end-user
This development involves creating a modular program.
The deliverables include:
❏ detailed design of the program structure
❏ test plan with completed test data table
❏ working program
❏ results of testing
❏ evaluation report
❏ This development work must be completed within 4 hours
EXAMPLE: BOUNDARIES
Boundaries: the limits that help to define what is in the project and what is not.
It can also clarify any assumptions made
❏ The program will read the pupil data (name, prelim mark and assignment
mark) for 20 pupils from a sequential text file not a database.
❏ The only output needed is the name and percentage of the pupil with the
highest percentage.
❏ It will not allow the user to select a file it will be pre-named
Assumptions (these can dictate the direction of development)
❏ The data is accurate, so there is no need to implement input validation.
❏ The pupil with the top mark will be the pupil who has the highest
percentage.
EXAMPLE: FUNCTIONAL REQUIREMENTS
These are defined in terms of the inputs, processes and outputs.All inputs are
imported from a sequential file and all outputs displayed on the screen.
The program is activated by double clicking on the file menu and then selecting
“Run” from the menu. Each process will be a separate procedure or function
that is called from the main program.
EXAMPLE: FUNCTIONAL REQUIREMENTS (CONT)
The inputs, processes and output required are shown below:
1. Inputs:
Read in the Pupil Name, Prelim Mark ,Assignment Mark from external file
2. Processes
Calculate the percentage for each pupil
Find the name and percentage of the pupil with highest percentage
3. Output
Display the name of the pupil with the highest percentage.
Display the corresponding percentage.

Analysis

  • 1.
  • 2.
    LESSON AIMS By theend of this lesson all pupils will be able to: ❏ Describe the function of the analysis phase ❏ Define the purpose, scope and boundaries of a piece of software ❏ Detail the Functional and User requirements of a piece of software ❏ Design solutions to problems detailing the data flow and any major refinements
  • 3.
    EXTRACTING THE CLIENTSNEEDS ● This is sometimes called requirements elicitation. This can be difficult as the client may not be fully aware of what might (or might not) be possible, and the software analyst will probably not be fully familiar with the client's business operations. ● The analyst might begin by interviewing the client company management and other staff as well as using questionnaires to get a clear statement of what needs to be done. ● The analyst might also make observation notes of the operations and workflow of the client's business to find out what actually happens in the workplace.
  • 4.
    DOCUMENTING THE CLIENTSNEEDS ● The end result of the requirements elicitation process is a formally written statement of what the client wants the design team to do - the software specification. ● The completed specification (agreed on by both parties) is the basis of a legally binding contract which can be used by either party to resolve possible disputes in the future. ● This document is also the basis for everything the software company goes on to make, so it is extremely important to get it right. ● Communication is NOT just a single event. There may be several meetings which have to take place between client(s) and the analyst. ● The need to clarify what has been said, and what is meant by what has been said, will often arise.This is an iterative process and is repeated until both sides are in complete agreement.
  • 5.
    COMMUNICATING REQUIREMENTS TOTHE DEVELOPMENT TEAM ● The development team may identify technical and financial limitations which may require compromises and revisions to the original requirements. ● Ideas may be too costly to implement. The client's hardware infrastructure may not be able to support aspects of the proposed software or certain ● The software specification therefore must clearly state the scope, boundaries and functional requirements of the proposed development. ● The (revised) specification is returned to the client to verify. This iterative process aims to ensure that the client will end up with a product that is fit for purpose, cost effective and delivered on time.
  • 6.
    PURPOSE, SCOPE ANDBOUNDARIES When performing the analysis stage of a project there are 3 things that have to be considered first ❏ Purpose ❏ Scope ❏ Boundaries
  • 7.
    PURPOSE, SCOPE ANDBOUNDARIES Purpose: a general description of the purpose of the software. Scope: a list of the deliverables that the project will hand over to the client and/or end-user, eg design, completed program, test plan, test results and evaluation report. It can also include any time limits for the project. Boundaries: the limits that help to define what is in the project and what is not. It can also clarify any assumptions made by the software developers regarding the client’s requirements.
  • 8.
    FUNCTIONAL REQUIREMENTS Once thepurpose scope and boundaries have been established then the requirements have to be established Functional requirements: the features and functions that must be delivered by the system in terms of inputs, processes and outputs.
  • 9.
    EXAMPLE: PURPOSE A teacherneeds a program that will process the prelim and coursework marks for their class of 20 pupils which are held in a file.They will also need to find the percentages and the best performing student. So the purpose is: To take 20 pupil names, their prelim marks and their assignment marks from a file. Calculate the percentage, and then find and display the name and percentage of the pupil with the highest percentage.
  • 10.
    EXAMPLE: SCOPE Scope: listof the deliverables that the project will hand over to the client and/or end-user This development involves creating a modular program. The deliverables include: ❏ detailed design of the program structure ❏ test plan with completed test data table ❏ working program ❏ results of testing ❏ evaluation report ❏ This development work must be completed within 4 hours
  • 11.
    EXAMPLE: BOUNDARIES Boundaries: thelimits that help to define what is in the project and what is not. It can also clarify any assumptions made ❏ The program will read the pupil data (name, prelim mark and assignment mark) for 20 pupils from a sequential text file not a database. ❏ The only output needed is the name and percentage of the pupil with the highest percentage. ❏ It will not allow the user to select a file it will be pre-named Assumptions (these can dictate the direction of development) ❏ The data is accurate, so there is no need to implement input validation. ❏ The pupil with the top mark will be the pupil who has the highest percentage.
  • 12.
    EXAMPLE: FUNCTIONAL REQUIREMENTS Theseare defined in terms of the inputs, processes and outputs.All inputs are imported from a sequential file and all outputs displayed on the screen. The program is activated by double clicking on the file menu and then selecting “Run” from the menu. Each process will be a separate procedure or function that is called from the main program.
  • 13.
    EXAMPLE: FUNCTIONAL REQUIREMENTS(CONT) The inputs, processes and output required are shown below: 1. Inputs: Read in the Pupil Name, Prelim Mark ,Assignment Mark from external file 2. Processes Calculate the percentage for each pupil Find the name and percentage of the pupil with highest percentage 3. Output Display the name of the pupil with the highest percentage. Display the corresponding percentage.