1. Systems Analysis and Design (Level 3)
Wednesdays
Rochford Campus
Boston College
Ask each student to say, in turn, their name and a bit about themselves and what software/computer systems development they have studied or done prior to this.

2. What is Systems Analysis and Design?
Investigating, understanding and analysing the IT requirements of business or organisational processes and from all the potential solutions, designing the chosen one.
In this context, system refers to the business/organisational processes (also referred to as business information systems since information is passed in these processes such as raising of invoices, delivery notes etc.).
Note that it is investigating, understanding and analysing the business needs may be more than what the users tell you. For example, a salesperson may believe that what the company requires is a new interactive, web-enabled, real-time, dynamic Orders system. The real problem might be that nobody really desires their products!
Following these procedures, the design is passed on to system developers (either programmers, network builders or database designers) for the implementation and deployment of the solution. Later, the analyst may design a test plan for the implemented solution as he/she will probably be able to select design the most appropriate test criteria based on his/her knowledge of the business or organisation.
In this module, we will not be implementing a solution and hence will not test one. Rather the focus is on the analysis of the requirements and the design of appropriate solutions. Notably, the requirements specification provides the basis for the testing and evaluation.

3. Motivation / Key Drivers
Significant IT project failures, taken from (Dennis et al, ‘Systems Analysis and Design’, 2010 (4th Ed))
Company
Year
Project Outcome in US Dollars
Hudson Bay (Canada)
2005
Inventory system problems lead to $33.3 million loss
UK Inland Revenue
$3.45 billion tax-credit overpayment caused by software errors.
Avis Europe PLC (UK)
2004
Enterprise resource planning system cancelled after $54.5 million spent
Ford Motor Co.
Purchasing system abandoned after deployment costing approximately $400 million
Before showing slide:
In the past, systems designers would speak to a couple of business managers and then go off and create a solution and deliver it after say a few months. Designing and building effective systems is not that easy!
Can you estimate the magnitude of losses due to failed IT projects of some national and multinational companies?
Now show slide:
cf., significant IT project failures where large national/multinational companies have abandoned projects worth millions of dollars before or shortly after deployment.
As I have just mentioned, users may not know what is actually required. There may be company politics involved which would colour the judgement of the particular interviewee involved during the information gathering phase, for example, not having a reasonable spend limit for their own department at the expense of other department(s).
The aim is not so much to create a wonderful or elegant solution …

4. Motivation / Key Drivers
Add value to the company i.e. perform work more efficiently, support organisational/business processes and goals increase business profits
Support business growth occurring through acquisitions or increased productivity
Create effective and affordable system solutions first time round
but rather:
to add value to the company (read above)…which ultimately lead to increased profits.
to support business growth (read above)
to create effective and affordable system solutions first time round is difficult – this can be helped by planning (lack of or incomplete planning can be costly in the end), identifying and solving the right problem first time round (recall the investigating, understanding and analysing of the business requirements that occurs in SAD) and using the life-cycle/concurrent/simultaneous engineering principle (i.e. considering all the system development phases concurrently).

5. Module Learning Outcomes
Understand the principles of systems analysis and design
Be able to carry out a structured analysis of business systems requirements
Be able to design business systems solutions
Read above.
Let us now consider the broader development process within which the analysis of requirements and system design falls.

6. Systems Development Life Cycle (SDLC)
Group Exercise:
Consider the commissioning of a dress-maker/tailor to produce your wedding dress/ball-gown/suit.
Collaborating in small groups (of say 2-3), try and identify the life stages of the garment before, during and after its creation.
If possible, illustrate these stages in a diagram.
Let the learners spend around 15 – 20 minutes to carry out this exercise.
Remember - Go round the groups and speak with the students and guide them.
As they come to an end of the exercise, point out that many of the life stages of the garment which they have identified comprise the stages of the general Systems Development Life Cycle.
Get the groups to draw their diagrams on the white board.

7. A System Development Life Cycle (SDLC) Illustration
Plan, choose dress design
Measurements, colour, material, etc.
Tailor makes pattern
Sews dress
You try it on
Repairs/Alterations
You feel that you want some new clothes and decide that you want a new dress. You read some magazines, talk to friends and choose a design. Then you approach a tailor with your design. He asks for more details, such as your body measurements, the colours of the garment, material to use etc..
The tailor then makes the pattern of the dress or the blue-print. He/she then sews it. You try it on. You test it to see whether it fits correctly.
Later, you return to make repairs or for alterations.
Finally, when you have had enough of it you either donate it, recycle it into something else or simply discard it.
Can you see how this Product Development Life Cycle (SDLC) has application to all sorts of products from the chair you are sitting on, to computer systems to aircraft?
Please take a few minutes and think about how the above diagram may be changed to reflect the application of the SDLC to the life cycle of say a chair, like the one you are sitting on?

8. System Development Life Cycle (SDLC)
Planning
Analysis
Design
Implementation
(Dennis et al.)
Defined
Investigated
Designed
Implemented and tested
Maintained and reviewed
(Fishpool and Fishpool)
Identifying problems, opportunities and objectives
Determining human information requirements
Analysing system needs
Designing the recommended system
Developing and documenting software
Testing and maintaining
Implementing and evaluating the system
(Kendall and Kendall)
In the ‘Systems Analysis and Design’ literature, several different versions of the System Development Life Cycle process are given.
Dennis et al:
Plan = Feasibility study - technical feasibility (can we build it), economic feasibility (will it provide business value), organisational feasibility (will it provide organisational value i.e. will it be used) and once approved, a work/project plan is devised.
Analysis = Study of the current system, requirements gathering, system proposal/requirements
Design = hardware, software, network infrastructure, user interface, etc.…
Implementation = system construction, installation/deployment, support/maintenance and improvement/repair.
The others have similar stages or they are self-explanatory.
And after the life of the product, there is the end of life phase i.e. disposal including landfill, recycling etc.

9. Established SDLC Models
Waterfall
V-shaped
Spiral
Rapid Applications Development (RAD)

10. Waterfall Model
The diagram implies that the system development process progresses sequentially from one phase or stage to the next until the end. Each phase must be completed before the next one can begin. There is no overlap of phases. At the end of each phase, a review takes place to determine if the project is on the right path and whether to continue or discard the project.
Advantages:
Simple and easy to understand and use.
Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.
In this model phases are processed and completed one at a time. No overlap of phases.
 Disadvantages of waterfall model:
Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.
No working software is produced until late during the life cycle.
High amounts of risk and uncertainty.
Not a good model for complex and object-oriented projects.
Poor model for long and ongoing projects.
Not suitable for the projects where requirements are at a moderate to high risk of changing.
When to use the waterfall model:
This model is used only when the requirements are very well known, clear and fixed. There are no ambiguous requirements
Product definition is stable.
Technology is understood.
Ample resources with required expertise are available freely
The project is short/small.

11. V-Shaped Model: Verification and Validation Model
Exercise:
Research the V-shaped model and understand its operation, pros and cons.
Make comparisons with other models

12. V-Shaped Model: Verification and Validation Model
Similar to the waterfall model, containing similar phases. Sequential path of execution of processes. Each phase must be completed before the next one begins. Go down the L.H.S and then up the R.H.S.
In this model, however, testing is planned concurrently with the development of each phase. The test plan focuses on meeting the functionality specified in the requirements gathering. Testing executed after implementation.
Understand the user requirements and establish the details of the system requirements. Plan tests to determine whether the user requirements have been fulfilled.
High level design focuses on system architecture and design. It provides an overview of the solution in relation to the systems around it. An integration test plan is created in this phase in order to test the ability of the pieces of the software systems to work together.
Low level design phase is where logical designs of the software components are devised. It includes class diagrams with all the methods and relations between classes. Component tests are created in this phase as well.
Advantages of V-model:
Simple and easy to use.
Test planning happens well before coding. This saves a lot of time. Hence higher chance of success over the waterfall model.
Proactive defect tracking enabling their detection at an early stage.
Avoids the downward flow of the defects.
Works well for small projects where requirements are easily understood.
Disadvantages of V-model:
Very rigid and least flexible.
Software is developed during the implementation phase, so no early prototypes of the software are produced.
If any changes occur midway, then the test documents along with requirement documents have to be updated.
High confidence of customer is required for choosing the V-Shaped model approach. Since, no prototypes are produced, there is a very high risk involved in meeting customer expectations.
When to use the V-model:
The V-shaped model should be used for small to medium sized projects where requirements are clearly defined and fixed.
The V-Shaped model should be chosen when ample technical resources are available with required technical expertise.

13. Rapid Applications Development (RAD) Model
RAD advocates a short development cycle. It is a ‘high-speed’ adaption of the linear sequential model in which rapid development is achieved by exploiting modularised design and developing the different modules concurrently. The different modules are then integrated to form the whole.
Business modelling: The information flow is identified between various business functions.
Data modelling: Information gathered from business modelling is used to define data objects that are needed for the business. The characteristics of each data object are identified and the relationships between them defined.
Process modelling: The data objects in the data modelling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting, or retrieving a data object.
Application generation: RAD emphasises software reuse or creation of reusable components with automation aiding in construction of the software.
Testing and Turnover: Since the RAD process emphasises reuse, many of the program components may have already been tested. This reduces overall testing time.
Advantages of the RAD model:
Reduced development time.
Increases reusability of components
Quick initial reviews occur
Encourages customer feedback
Integration of modules from very beginning solves a lot of integration issues.
Disadvantages of RAD model:
Depends on strong team and individual performances for identifying business requirements.
Only systems that can be modularised can be built using RAD
Requires highly skilled developers/designers.
High dependency on modelling skills
Inapplicable to cheaper projects as cost of modelling and automated code generation is very high.
When to use RAD model:
RAD should be used when there is a need to create a system, that can be modularised, in the order of 2-3 months time.
It should be used if there is a high availability of designers for modelling and the budget is high enough to employ them along with the cost of automated code generating tools.
RAD should be chosen only if resources with high business knowledge are available and there is a need to produce the system in a short span of time (2-3 months).
RAD is not appropriate when the technical risks are high. This occurs when a new application makes heavy use of new technology or when the new software requires a high degree of interoperability with existing computer programs.
When there is commitment from both the developers and customers to the rapid process and all that that entails.

14. Generic life cycle model
determining the problem scope (also known as the “problem domain”)
gathering requirements
writing the specification
designing a solution
coding the design
testing the program code
writing documentation
reviewing and maintaining the solution
A general SDLC model can be defined as follows:

15. Investigation needs to focus on:
Data
Procedures
Future needs
Management needs
Pros and cons of the existing system

16. Requirements Analysis
Once investigation has revealed what the system currently does, a
requirements analysis and specification are developed.
The requirements analysis focuses on:
what the new system will need to do (the functionality)
the necessary inputs
the processing requirements,
the outputs predicted.
At this stage, however, there are no suggestions as to how the
functionality will be achieved. The specification will contain a list of any identified hardware or software requirements, or anything else (e.g. furniture, equipment) that will be needed.

17. Design (Logical and Physical)
Design starts with an abstract representation of the new system (including data flows, inputs and outputs) using diagrams and supporting text. Logical design specifies what the new system will do. Diagram formats used:
Entity relationship models (ERM) for modelling data
Data flow diagrams (DFD) for modelling processes and interactions
In addition, other design tools may be used:
Data table or data dictionary
Program design tools
Network diagrams
Physical design concentrates on the environment within which the new system will be running. It considers storage requirements and database design, performance issues, pseucode, network architecture (including cabling, IP addresses, security…), user-interface design and so on.

18. System Construction This involves:
Writing the program, developing the database, installing the network etc.
Documenting the solution (technical and user)
Testing the system
This would be undertaken by a development team, working directly from the designs written earlier.

19. System Deployment
Once successfully tested, the new system needs to be formally implemented. Users will need to change from the old system to the new.
Four possible changeover strategies may be used:
Direct changeover – new system replaces old system immediately
Parallel conversion (or parallel running) – both run simultaneously for a period
Phased conversion – new system is added a bit at a time
Pilot conversion – new system is introduced in just one branch of a organisation to see how it fairs.

20. Maintenance
Once the system is in place, maintenance activities will begin.
These include:
Corrective action – fixing problems identified in the system
Perfective maintenance – making the system work better
Adaptive maintenance – making changes; expanding the system
Generally these activities will occur chronologically in the order listed.

21. Review
The final stage of the life cycle is the review. All individuals involved in the development of the system will discuss and evaluate the project, the process and the outcome!
This means that each stage of the life cycle will be discussed (good and bad).
It is through this process that analysts, developers and project managers learn.
When undertaking the next project they will feel more confident about what went well and will try and anticipate and avoid anything that went badly.
Eventually, through review activities, a new project may be defined and the whole process will begin again (hence the term ‘life cycle’).