When developing software we must be aware of its purpose. The stage of recognition and creation of a solution design is called analysis, because it involves analysing the functionality of the system. The analysis can be performed only at the beginning of software development or in an iterative manner along with the development of the system, and can have different scope and form of implementation. In this discussion I will focus on systems analysis. But before we get to it, let’s examine whether analysis is needed and how it has been incorporated into various software development models. We will compare systems analysis with business analysis and look at the products of system analysis.
Is the analysis needed?
Many people claim that the preparation of requirements and documentation for a particular system is not necessary, and that analysis is just a waste of time. That it is better to get down to implementing a solution and skip the preceding steps. After all, the system will be developed anyway. Besides, it will be faster and cheaper this way. However, is it really possible to develop a system without the analysis? Let’s assume the simplest of all possible scenarios – we develop the system ourselves and we are its recipients – we do not have to ask anyone how the final product should look like or explain it to anyone, because we will design it ourselves. It would seem that the analysis is completely unnecessary in this case scenario. Yes, we do not have to compile extensive documentation, we define the requirements ourselves, and the design is formed in our head. Is it not the analysis then? Do we not determine for ourselves what our system is supposed to do? Maybe we do not have everything set at the very beginning, before we start implementation, but during system development we define what it should do, what functionality it should have, what parameters it should accept and what result it should give. This data is not always written down, although there probably are some notes scattered around, with fragments of certain ideas.
In more difficult cases, when the recipient of the solution is someone other than we ourselves, we need to perform a more extensive and formalised analysis. We need to find out what this person’s expectations are and what requirements the system should meet. Additionally, we often need to be familiar enough with the subject matter to anticipate system functionalities that the recipient has not told us about. There may be functionalities that they deemed obvious so they did not mention them, or they did not know they would need them. In this case, it is necessary to conduct an analysis to determine the requirements of the user of a given system.
In addition, the matter becomes even more difficult if the system is so complex that we cannot implement it alone and we need help of a larger team. This team should have extensive knowledge so that they can work together to deliver a system that serves a clear purpose. The description of the functionality that we have in mind will unfortunately not be of any use here. We must clearly present the functionality of our solution and separate its fragments so that individual people can implement them without hindering each other’s work.
The analysis is therefore necessary regardless of the solution it is performed for. Its result may have different form and scope, adjusted to our needs.
Is analysis included in various software implementation models?
In the international standard for describing methods of selection, implementation and control of the software life cycle – ISO/IEC 12207[1] one of the basic processes is development. This is the most elaborate process in which development includes creating a system from scratch and modifying it. This process consists of a number of activities, among which the initial ones concern requirement analysis and design. The development process tasks defined in the standard include:
- systems requirements analysis,
- system design,
- software requirements analysis,
- architectural design,
- detailed design,
- software coding and testing,
- software integration,
- software system tests,
- system integration,
- system tests,
- software installation,
- software acceptance monitoring.
There are many models of software development processes. There are, among others:
- Waterfall Model
- Spiral Model
- Iterative and Incremental Model
- Rational Unified Process (RUP)
- Agile Software Programming
In case of the Waterfall or Classical Model, analysis is a clearly indicated process, but in case of Agile methods it is no longer so obvious.
Waterfall Model
The Waterfall Model[2] involves sequential execution of activities that are successive phases of the design. Before the next phase can begin, the previous one must be completed and thoroughly described. The first two phases of this model, namely requirement specification and design, include the analysis.
Spiral Model
The Spiral Model[3] assumes a cyclic sequence of activities that lead to the target solution. The main feature of the spiral model is the analysis of risk in each phase. System development begins with the formulation of the main requirements, followed by an analysis of the works in progress and an assessment of alternative solutions. In this way, prototypes of the system are created.
Iterative and Incremental Model
In case of the iterative and incremental model, at the beginning we deal with defining requirements, after which a subset of system functions is selected – the “increment”, for which an analysis is performed and a design is created. After the implementation of a given scope it is tested and then a given version of the system is delivered to the client.
RUP
Rational Unified Process[4] is an iterative structure of software development process. In each iteration, a piece of the system is created and made available to the client. This way we can get a quick feedback and make sure that the designing team has understood the client’s requirements and expectations well. The RUP life cycle is based on an incremental model of the software life cycle with four phases: inception, elaboration, construction, transition. In each iteration, we can obtain work results from six domains:
- business modelling,
- requirements,
- analysis and design,
- implementation,
- test,
- deployment.
Phases and disciplines of RUP
Agile Software Programming
This group of software development methods is based on an incremental and iterative model of the software development life cycle. Due to the following manifesto provision: “Working software over comprehensive documentation” and the lack of a direct indication of the analyst’s role in examples of agile methodologies it is often thought that in this method the analysis is not performed. Of course, this is not entirely true. Even if only the Agile model is used, analysis is still performed – requirements must be gathered to determine what tasks the team is to perform, and the team may be responsible for analysing and designing the solution. Although the role of an analyst in agile programming methods is not clearly defined, they can work outside the team or as a part of it. When working outside the team, the analyst works iteratively, outside of sprints, and provides analysis products to the team well in advance. The analyst working in a team performs analytical work according to the iterations of the team. The analyst works with the team and prepares the minimum required documentation and their primary responsibility is to communicate with the team.
Analyst in Agile Software Programming
What is the difference between business and systems analysis?
As it is often the case with terms, they have multiple definitions and are understood differently by different people. It is the same with business and systems analysis. Business and systems analysis are part of the analytical process which is one of the most important stages of system design. Business analysis is performed by analysts responsible for creating and optimizing business processes. Systems analysis is performed on the development side by analysts who model the functionality of the system. In many cases, separating business and systems analysis is very difficult because the difference between them depends on the particular organization and its practices.
Systems analysis requires involvement in the solution design and testing processes. It focuses more on how a technology solution should work and what interfaces it should share with external systems. Systems analysis is related to technology. It aims at identifying the information systems that can help the organization to achieve its business objectives. In this case, either existing systems or new ones are being designed.
Business and systems analysis tasks
| Business analysis | Systems analysis |
|
|
The main tasks of business analysis are to analyse the organization’s business processes, contact stakeholders, analyse stakeholders’ needs, identify business requirements, identify solutions or improvements, document and evaluate the collected data. In case of systems analysis the following tasks are carried out: transformation of business requirements into technical ones, contact with developers, system design to meet business objectives, development of documentation (specifications, diagrams, flowcharts) for developers and deployment supervision.
Due to the lack of clarity in defining the business and systems analysis, there are also problems in interpreting the term of a business analyst and a systems analyst. According to [5][6], a business analyst is a person who performs business analysis activities [1][2]. Business analysts and information systems consultants work with clients to identify and document requirements, conduct business and technical studies, design, build, integrate, and implement IT business solutions, and provide advice on strategy, policy, management, security, and delivery of information systems[7]. The business analyst is a person who has the competence to perform activities concerning the agreement and support of stakeholders (parties) in the development and operation (maintenance) of a solution in all phases of its life cycle[8]. A systems analyst, on the other hand, is a person who conducts research, analyses and evaluates clients’ IT requirements, procedures or problems, and creates and implements proposals and recommendations, as well as plans and improves current or future IT systems[9]. The different responsibilities mean that each of these roles requires somewhat different skills which are shown in the figure below.
Business and systems analyst skills
Systems analysis requires different skills. Communication skills are crucial in this case, as a person on this position has to be able to establish contact with other people. The technical skills, however, will help them verify the feasibility of given functionalities and often propose other possible solutions.
What is produced during the systems analysis?
The systems analysis includes:
- defining systems requirements that are an extension of business requirements (developed as a part of business analysis);
- determining the input and output data of the system;
- verifying whether the proposed solution is efficient and cost-effective;
- cooperating with developers, discussing developed diagrams and flowcharts;
- verifying system performance,
- coordinating tests and their observation.
The systems analysis includes all the products made by the business analysis. Collected and created business requirements are developed and detailed to define systems requirements.
Business requirements and systems requirements
| Business requirements | Systems requirements |
|
|
The systems requirements can be presented in the form of User Stories. These are brief descriptions of the features and characteristics of the system that coalesce the vision and the desired effect. The content of the User Story is usually presented in the form of the following template:
As an <actor> I can <action>, so that <benefit>
where:
- Actor – indicates a particular type of user.
- Action – indicates what a given persona is about to do in the system.
- Benefit – defines the meaning of the implementation i.e. the value provided.
For each story, a list of acceptance criteria must be defined that specify what parameters should be ensured to accept a given User Story.
One of the main goals of systems analysis is to develop a system model that describes it from the user’s point of view. Models are built to better understand the system that is being developed. Thanks to them we can present the system design, system structure specification and its behaviour, and to document the decisions made.
To model business processes, the following notations are used: BPMN ( Business Process Modelling Notation)[10] and UML (ang. Unified Modelling Language)[11]. BPMN allows you to create clear data flow diagrams. These diagrams can be created at different levels from very high, people-oriented to technical ones, depicting e.g. IT process flows. UML is dedicated to modelling information systems but it also has notation extensions dedicated to modelling business processes.
Basic UML diagrams in business and systems analysis
| Business Diagrams | Business Use Case Diagram
Business Object Diagram Domain Model State Machine Diagram Activity Diagram Sequence Diagram |
| IT Diagrams | Systems Use Case Diagram
Activity Diagram State Machine Diagram Class Diagram Sequence Diagram |
For business modelling, the first step is to define the interactions between entities outside the system and the business processes. This interaction is documented in the form of Business Use Case Diagrams. Additional diagrams that can be used for business analysis are Business Object Model, State Machine Diagram, Domain Model, and Activity or Sequence Diagram. The Business Objects Model depicts the data for the business, defines the positions established in the organization and the objects that are used, developed, studied or controlled by business employees. The Domain Model is used to juxtapose the concepts defined and used in relation to the system. The State Machine Diagram defines a sequence of states assumed by an object depending on events occurring during its life cycle.
In case of systems analysis, the most commonly used diagram is the Use Case Diagram which represents the functionality of the system. It provides an abstract view into the information system. It defines the inside of the system – the use cases and the actors and relationships that exist between them. In order to present detailed information about the system, this diagram is supplemented with documentation that describes the scenarios of individual use cases. Additional basic diagrams that are used for systems analysis are:
- Activity Diagram – it shows the sequence of steps that is performed when modelling a piece of the system,
- Sequence Diagram – it shows the interaction between objects and time it takes;
- Class Diagram – it shows the structure of the system by illustrating the structure of classes and relationships between them.
There are many tools available, both commercial and free, that enable visualization of models via commonly used notations – UML, BPMN. The most well-known modelling tools are Visual Paradigm or Enterprise Architect. The tools help to employ all the possibilities such notations provide and to create simplified process diagrams that can also achieve the goal you set for them.
Summary
Systems analysis is a process that occurs in every software implementation model. It can be performed only at the very early stage of the software development process or iteratively as the system grows. The role of the analyst is usually assigned to the person employed in this position, but in the absence of such a person, it may be assigned to individual people in the team responsible for system development.
The number and form of documents developed as part of the analysis should be adapted to the needs of a given project. The developed documentation should include the minimum scope that allows the system to be modelled and presented to both the business and the developers responsible for its implementation. The form of this documentation should be agreed with the team so that it presents the scope and functionality of the system in the simplest and most understandable way.
***
Reference list:
[1] “ISO/IEC/IEEE 12207:2017”. Standards catalogue. International Organization for Standardization. November 2017. Retrieved 21 June 2018.
[2] Royce, Winston W. “Managing the development of large software systems: concepts and techniques.” In Proceedings of Westcon, IEEE CS Press, 1970, p. 328-339
[3] Boehm, B. (1986). A spiral model of software development and enhancement. ACM SIGSOFT Software engineering notes, 11(4), 14-24.
[4] Kruchten, Philippe (2004-05-01). The Rational Unified Process: An Introduction. Addison-Wesley. p. 33. ISBN 9780321197702. Retrieved 2014-12-17.
[5] A Guide to the Business Analysis Body of Knowledge®, Version 2.0, International Institute of Business Analysis, Toronto 2009, http://www.theiiba.org
[6] A Guide to the Business Analysis Body of Knowledge®, Version 3 Public Review, International Institute of Business Analysis, Toronto 2014, http://www.theiiba.org.
[7] The National Occupational Classification 2011 (NOC 2011), Human Resources and Skills Development Canada and Statistics Canada, s. 214.
[8] Jerzy Leyk: Role analityka biznesowego – standard ITIL versus BABOK
[9] ISCO-08 Draft definitions, ISCO International Standard Classification of Occupations, July 2009, http://www.ilo.org/public/english/bureau/stat/isco/docs/gdstruct08.doc
[10] https://www.omg.org/spec/BPMN/
[11] https://www.uml.org/what-is-uml.htm
