TOPCIT Software | 05. Software Requirements Analysis

Summary

This script discusses the software development lifecycle, emphasizing the V-model and its iterative phases. It highlights the importance of requirements analysis to enhance communication, reduce defects, and enable code reuse. The video introduces structured analysis and object-oriented methodologies, using examples like the automobile cruise control system and bank deposit services to illustrate the process of creating system context diagrams, data flow diagrams, and use case diagrams. It also touches on the significance of modeling languages like UML in advancing from code-based to model-driven development.

Takeaways

• 📈 The V-model is a fundamental concept in software engineering, illustrating the development lifecycle with various outputs at each phase that are closely related and serve as inputs for subsequent phases.
• 📝 System requirements documents are crucial as they reflect all the requirements gathered by marketing and are further developed with internal and external standards and constraints.
• 🔍 Errors in requirements are a significant cause of rework in the testing phase, with IAG consulting stating that over 40% of the development budget is wasted due to incorrect requirements.
• 🗣️ Software requirements analysis and specification activities are vital for improving communication efficiency among developers and reducing development costs by identifying and addressing issues early on.
• 🛠️ Unified Modeling Language (UML) was developed to facilitate better understanding and communication of complex software structures among developers.
• 🔄 The systematic approach to requirements analysis and specification helps in reducing defects and associated costs by identifying issues early in the development process.
• 🔄 Defects found later in the development process can exponentially increase the cost of fixing and maintaining them, emphasizing the importance of early detection through systematic development.
• 🔄 Source code reuse is a significant advantage of software requirements analysis and specification, especially in complex systems where code-based development has limitations.
• 🌐 The global trend is moving towards Model-Driven Development (MDD) and Model-Driven Testing (MDT) as a way to overcome the limitations of code-based development techniques.
• 🔧 Structured analysis is commonly used in system analysis and embedded system analysis, focusing on defining the 'what' of the system rather than the 'how', using data flow diagrams and state machine specifications.
• 🚗 The development process of the automobile cruise control system is used as an example to illustrate the application of structured analysis, emphasizing the importance of understanding system context and decomposing processes.

Q & A

What is the V-model in software engineering?

The V-model in software engineering is a development lifecycle model that describes the various outputs developed at each phase of the software development process. It emphasizes that outputs from one phase are used as inputs for the next, creating a 'V' shape when visualized.

Why are system requirements documents important in the software development lifecycle?

System requirements documents are crucial because they reflect all the requirements gathered by marketing and other teams, and they incorporate internal and external standards, constraints, and environmental conditions. They serve as the foundation for developing the product and ensuring that child documents meet all the requirements of the parent document.

What is one of the main causes of rework in the testing phase of software development?

One of the main causes of rework in the testing phase is errors in the requirements, such as misunderstandings, missing requirements during development, or not reflecting changes in requirements.

How much of the total development budget is wasted due to wrong requirements according to IAG consulting?

According to IAG consulting, more than 40% of the total development budget is wasted due to wrong requirements.

What are the three main effects of analyzing and specifying software requirements?

The three main effects are increased efficiency of communication among developers, solving problems in a systematic way to reduce defects and costs, and enabling source code reuse.

What is Unified Modeling Language (UML) and why was it created?

Unified Modeling Language (UML) is a standard modeling language used in software engineering to visualize and specify the design of a system. It was created to make it easier to understand and communicate with the system when many developers are working on it simultaneously.

What is the significance of structured analysis in system analysis and embedded system analysis?

Structured analysis is significant because it focuses on defining what the system should do by analyzing the requirements and constructing a specification for the logical function. It identifies the information flow between functions without focusing on the specific details of the functions to be implemented.

What is a data flow diagram (DFD) and why is it used in structured analysis?

A data flow diagram (DFD) is a visual representation that emphasizes the flow of information and deliberately ignores the control sequence. It is used in structured analysis to express information flow between functions more concisely.

What is the role of a state machine specification in embedded system analysis?

A state machine specification is used in embedded system analysis to explicitly show cases and events that might occur in the future. It helps in expressing analysis and decisions on various combinations without missing any potential scenarios, thus preventing defects.

Can you explain the structured analysis process as described in the script?

The structured analysis process involves creating a system context diagram to understand overall system behavior, performing stepwise decomposition to break down processes across multiple levels, and creating a process specification for each process by detailing inputs, outputs, and contents.

What is the purpose of creating a system context diagram in the development of the automobile cruise control system?

The purpose of creating a system context diagram is to illustrate the extent to which the automobile cruise control system interacts with the car and to understand the overall system behavior and context based on the given requirements and system configuration.

What is the importance of a data dictionary in the development process?

A data dictionary is important as it defines the details of the data shown in the data flow diagram. It includes meaningful information for future design, such as the range of values, and is essential for understanding the inputs and outputs of each process.

How does object-oriented development methodology differ from structured analysis in terms of requirements analysis?

Object-oriented development methodology focuses on identifying actors and their goals, creating use cases to express the relationship between actors and system functionalities, and using diagrams like use case diagrams to represent these relationships. It differs from structured analysis, which uses data flow diagrams and focuses on information flow and system functions.

What is the purpose of a sequence diagram in object-oriented development?

A sequence diagram in object-oriented development is used to represent the dynamic behavior of the system. It shows the interactions between objects over time, including the sequence of messages passed between them and the responsibilities assigned to each object during specific events.

Why is it important to write a requirements specification based on industry standards?

Writing a requirements specification based on industry standards ensures clarity, verifiability, and consistency in the description of how the input is transformed into output. It provides developers with all the necessary details to design the system and helps in creating a clear and standardized understanding of the system's functionalities.

What is the significance of functional requirements in a software requirements specification?

Functional requirements are significant because they include all the details a software developer needs to design the system. They describe the transformation of input into output and are the most important item in the specification, as they must be clear and verifiable.

How can the use of diagrams in a requirements specification help in the development process?

The use of diagrams in a requirements specification helps in visualizing the system's structure and behavior, making it easier to understand complex relationships and interactions. It also aids in selecting the appropriate diagram based on the application methodology, such as data flow diagrams for structured techniques, use case diagrams for object-oriented methodologies, and process decomposition diagrams for information engineering methodologies.

Outlines

00:00

📈 Software Development Lifecycle and V-Model

This paragraph introduces the software development lifecycle and the V-model, emphasizing the iterative nature of development where outputs from one phase serve as inputs for the next. It discusses the importance of system requirements documents, which should incorporate marketing requirements and corporate standards. It highlights the common issue of rework due to errors in requirements, which can waste over 40% of the development budget. The paragraph underscores the need for effective software requirements analysis and specification to improve communication among developers, enhance development efficiency, and reduce defects and costs.

05:00

🔍 The Impact of Software Requirements Analysis

This section delves into the benefits of software requirements analysis and specification, such as improved communication and systematic problem-solving to reduce defects and costs. It explains how the complexity of software development can lead to increased defects, which are often discovered late in the development process, resulting in higher costs for correction. The paragraph advocates for systematic development to catch defects early and save on costs. Additionally, it discusses the advantages of source code reuse in model-based development, facilitated by UML, which can lead to higher quality applications and easier code reuse, contrasting this with the limitations of code-based development.

10:02

🛠 Structured Analysis and System Development

The paragraph discusses structured analysis, a method commonly used in system and embedded system analysis. It describes the analysis phase's goal to define the 'what' of the system, focusing on information flow rather than specific implementation details. The use of data flow diagrams and state machine specifications is highlighted as a way to express system behavior concisely and to handle unexpected events. The structured analysis process is exemplified by the development of an automobile cruise control system, detailing the steps from system context diagram to data flow diagram and data dictionary creation.

15:04

🏦 Object-Oriented Development for Banking Services

This section presents an object-oriented development approach applied to the creation of a banking system supporting deposit services. It outlines the process of identifying actors and their goals, distinguishing between primary and secondary actors, and setting system boundaries. The development of use cases and use case diagrams is explained, showing how to refine these to include common behaviors and sub-use cases. The paragraph also covers dynamic behavior analysis through sequence diagrams, illustrating the interactions between objects and actors in scenarios such as account opening.

20:05

📝 Writing Software Requirements Specifications

The final paragraph focuses on the process of writing software requirements specifications in accordance with industry standards, using the example of a bank's software requirements. It emphasizes the importance of clear and verifiable functional requirements, which detail how inputs are transformed into outputs. The paragraph suggests using appropriate diagrams based on the development methodology, such as data flow diagrams for structured techniques, use case diagrams for object-oriented methodologies, and process decomposition diagrams for information engineering methodologies. It also touches on the definition and specification of base processes or use cases, including input-output specifications and external interface data.

Keywords

💡V-Model

The V-Model is a software development lifecycle model that emphasizes a staged process where each phase is verified before proceeding to the next. In the video, it is described as a framework where various outputs are developed at each phase, with outputs from one phase serving as inputs for the next, ensuring a systematic approach to software development.

💡System Requirements Document (SRD)

A System Requirements Document is a key deliverable in software development that outlines the requirements for the system to meet. In the script, it is mentioned as being based on top-level requirements such as marketing requirements, and it should reflect all gathered requirements while also incorporating corporate standards and environmental conditions.

💡Unified Modeling Language (UML)

Unified Modeling Language is a standard notation used for software system modeling. The script discusses UML as a tool born to facilitate better communication among developers by providing a blueprint that can be easily understood at a glance, thus improving development efficiency.

💡Rework

Rework in the context of software development refers to the effort required to correct issues that arise during the development process. The video mentions that a significant amount of the development budget is wasted due to wrong requirements, which often leads to rework in the testing phase.

💡Software Requirements Analysis

This is the process of examining and specifying software requirements to ensure they are clear, feasible, and meet stakeholders' needs. The script highlights its importance in increasing communication efficiency among developers, solving problems systematically, and enabling source code reuse.

💡Model-Driven Development (MDD)

Model-Driven Development is an approach in software engineering where the development process is driven by models rather than code. The video discusses the global trend moving from code-based to model-based development, indicating a shift towards a more efficient and systematic development process.

💡Structured Analysis

Structured Analysis is a systematic approach to system analysis that focuses on identifying the information flow between functions. The script describes its use in embedded system analysis, where it aims to define the logical function of the system by constructing a specification based on the requirements.

💡Data Flow Diagram (DFD)

A Data Flow Diagram is a visual representation used to show the flow of information within a system. The video script uses the DFD as an example of how to represent the interactions and information flow in the development of an automobile cruise control system.

💡State Machine Specification

A State Machine Specification is a notation used to describe the behavior of a system in response to various events. The script mentions its usefulness in the analysis phase, especially for embedded systems, as it helps to explicitly show possible cases and events, thus preventing defects.

💡Object-Oriented Development

Object-Oriented Development is a methodology that uses objects and classes to design software. The script provides an example of developing a deposit service system using this methodology, focusing on identifying actors, their goals, and the relationship between use cases.

💡Sequence Diagram

A Sequence Diagram is a type of UML diagram that shows the interactions between objects in a particular scenario. The video script describes how to develop a sequence diagram for a use case of deposit in a banking system, illustrating the dynamic behavior and responsibilities of participating objects.

💡Requirements Specification

A Requirements Specification is a document that contains a detailed and verifiable description of the software's functional requirements. The script provides an example of how to write such a specification for a banking system, emphasizing the importance of clarity and the use of appropriate diagrams.

Highlights

The development lifecycle of software engineering is described by the V-model, emphasizing the relationship between development phases and their outputs.

System requirements documents are created based on top-level requirements and should reflect all gathered requirements along with corporate and environmental constraints.

Rework in software development is common, especially due to errors in requirements, which can waste more than 40% of the development budget according to IAG Consulting.

Software requirements analysis and specification activities are crucial for efficient communication among developers and improving development efficiency.

Unified Modeling Language (UML) was developed to facilitate understanding and communication with the system during software development.

Requirements analysis and specification can solve problems systematically, reducing defects and costs in software development.

Defects found later in the development process are more costly to fix; thus, systematic development and early defect detection are essential for cost efficiency.

Software requirements analysis and specification enable source code reuse, which is indispensable for complex software development and meeting time-to-market demands.

Model-based development using UML provides a mechanism for higher quality application development and easier code reuse.

The global trend in software development is moving towards Model Driven Development (MDD) and Model Driven Testing (MDT) as an advancement from code-based techniques.

Structured analysis is commonly used in system and embedded system analysis, focusing on defining the 'what' of the system rather than the 'how'.

Data flow diagrams and state machine specifications are key tools in structured analysis for expressing information flow and handling external events.

The structured analysis process involves creating a system context diagram, stepwise decomposition, and process specifications to understand overall system behavior.

Object-oriented development methodology involves identifying actors, goals, and use cases to map system requirements and functionalities.

Use case diagrams in UML distinguish between primary and secondary actors and help in expressing the relationship between actors and use cases.

Sequence diagrams in object-oriented analysis show the dynamic behavior of a system, detailing the interactions between objects and their responsibilities.

Requirements specifications should be clear, verifiable, and include all necessary details for software developers to design the system.

Functional requirements in a software requirements specification describe how input is transformed into output and are essential for system design.

Process decomposition diagrams, use case diagrams, and data flow diagrams are used in different development methodologies to describe the system's functional aspects.

Input-output specifications and external interface data definitions are part of the requirements specification process, ensuring clarity and verifiability.

Transcripts

[Music]

[Music]

[Music]

[Music]

[Music]

[Music]

[Music]

[Music]

the development lifecycle of software

engineering is generally described by

the v-model as shown on the screen the

number of various outputs are developed

at each phase of development in this

life cycle of these some of the outputs

may exist independently but most of the

outputs are closely related in other

words the output created at a specific

phase of development is used as input

for the next phase resulting in the

deliverables of that stage for example

you can create system or product level

system requirements documents based on

top level requirements such as marketing

requirements documents collected by the

product planning team these system

requirements documents should reflect

all of the requirements gathered by

marketing in addition it is further

created with adding internal and

external corporate standards constraints

and external environmental conditions to

develop the product

thus the child document must satisfy all

the requirements mentioned in the parent

document and a lot of rework from

software development efforts are common

in the testing phase which is the later

part of the development process one of

the main causes is known to be due to an

error in the requirements for example

misunderstanding of requirements

requirements missing during development

phases errors that do not reflect

changes in requirements I AG consulting

says more than 40% of the total

development budget is wasted by wrong

requirements so how can we avoid these

errors it is in software requirements

analysis and specification activities we

analyze software requirements and make

specifications when developing software

analyzing and specifying software

requirements in this way has three

effects first it increases the

efficiency of communication among

developers as you can see on the screen

two developers are discussing the system

however when one verbally explains the

complex software structure they are not

able to communicate with each other but

if you have a blueprint that shows the

same thing at a glance it's much easier

to understand it also improves

development efficiency because the

communication between developers is much

smoother the larger the project the more

communication between developers so even

if you only spend less time in

communication you can spend more time on

development to this end unified modeling

language was born in other words

modeling makes it easier to understand

and communicate with the system when a

lot of developers are developing at the

same time second the requirements

analysis and specification can solve the

problems in the systematic ways in other

words there is a systematic mechanism to

reduce defects and costs from software

look at the graph on the screen the

limitations of code based development

can be seen as the software becomes more

complex and result in losing system asta

City therefore the proportion of defect

is significantly increased it's a bigger

problem however is that these defects

are likely to be found later in the

development in other words defects

actually occurred at the beginning of

development but it is not found there it

is often found at later phases of

development the later you discover a

defect increase exponentially in the

cost of fixing and maintaining it

therefore if you develop more

systematically and find defects in the

early phase you will not be delayed in

correcting the defects in the later

phase of the development process and you

will also be able to save costs in other

words it is possible to drive more

efficient development let's look at the

third part the greatest effect you can

get from software requirements analysis

and specification is the source code

reuse the drawback of code based

development is that code reuse is

difficult for smaller developments where

the software was not complicated you may

not have felt the need for code reuse it

would not have been a big inconvenience

to develop new software for each new

product even if you reuse it you would

have to go ahead and apply the old codes

all at once and debug it for the new

product however as with recent trends

consider the case in which a product is

connected to multiple products and

merged together

that results in complex software code

reuse is indispensable to meet the time

to market in case of model-based

development using UML it provides a

mechanism in which various kinds of

application can be developed together

with the idea providers and

implementation specialists as a result

you can create higher quality

applications and make code reuse easier

as such there is some limitation to

develop smart devices with just code

based development technique modeling a

way to go beyond these limits as you can

see on the screen the global trend has

already been moving into model base from

the code base in other words we are

advancing to MDD model driven

development and MDT model driven testing

in the past

assembly language has become in common

and as software has become more

complicated the use of assembly language

which is very common to the machine

language has become more and more

limited thus the languages such as C C++

and Java have emerged to become popular

but as the software has become so

complicated that languages such as C C++

and Java are facing the challenges and

limitation again the modeling language

has emerged as a way to overcome this

[Music]

structured analysis is the most used in

system analysis and embedded system

analysis the analysis phase aims to

analyze the requirements and then

construct a specification for the

logical function because the purpose of

the analysis is to define what of the

system to be developed it focuses on

identifying the information flow between

functions and functions that construct a

system rather than the specific details

of the functions to be implemented to do

this a data flow diagram that emphasizes

the flow of information and deliberately

ignores the control sequence is applied

by not expressing the control sequence

in this way it is possible to express

information flow between functions and

function more concisely also there is a

state machine specification a notation

that is useful in the analysis phase due

to the nature of the embedded system the

system must be able to respond

appropriately to external events that

cannot control their order if a

developer has a unexpected situation and

events this leads to a defect the state

machine specification explicitly shows

cases and events that might be in the

feature as a result it provides

techniques for expressing the analysis

and decisions on various combinations

without missing the screen briefly

described the structured analysis

process when companies in the field

analyze requirements they have been

doing with these three steps if there is

a problem with the user the customer or

the field the first thing is to create a

system context diagram to understand the

overall system behavior and context

second do a stepwise decomposition

repeat for all processes to break down

the process across multiple levels the

third is to create a peace spec for each

process and run the requirements

analysis and specification tasks by

describing in detail what inputs outputs

and contents each process has

now this is the structured analysis

method here we will look at the

development of the automobile cruise

control system which is widely used as

an example of embedded system this

system provides the ability to maintain

the specified speed by performing its

operation instead of drivers Excel

operation when appointing a specific

speed for the driver's convenience the

screen is a brief description of

requirements related to the ACC system

after reading this requirements

statements please review the development

process on the following screen the

figure on the screen is the system

context diagram for automobile cruise

control example based on the given

requirements and system configuration

this system context diagram illustrates

the extent to which the automobile

cruise control system interacts with the

car according to the system context

diagram the automobile cruise control

system to be developed as functions to

control the throttle mechanism by

accepting input from driver shaft sensor

engine sensor for position lever brake

sensor and digital clock these external

elements are represented by a rectangle

that represents input output in dfd

notation and the automobile cruise

control to be developed is represented

by a circle that represents a process in

the DFT notation the arrow between the

process and the input output indicates

the flow of information information is

described in dotted lines for events

that reflect the importance of the point

of occurrence in addition data that does

not reflect the importance of the point

of occurrence is represented by a solid

line now

let's create a data flow diagram the

data flow diagram of the automobile

cruise control system that was first

decomposed based on the system context

diagram is shown in the figure as shown

in the figure the functions of the

automobile cruise control are divided

into distance and speed measurement

which calculate large axles of car and

automobile control which controls the

entire automobile cruise control this

first decomposition identifies the key

function of the system and is usually

split into seven to ten major functions

please note that this example is not

common because the nature of the example

has only two decomposed processes once

you have created a data flow diagram you

will need to develop a data dictionary

the data dictionary defines the details

of the data shown in the data flow

diagram the items described in the data

dictionary are things that are

meaningful for future design such as the

range of values the screen is part of a

data dictionary created during the

actual development of the automobile

cruise control system please click the

mouse button to see the contents this

time we will look at the requirements

analysis by object oriented development

methodology the example is system

development of deposit service to

support the business a bank is trying to

develop a system to support the deposit

service for customers assuming the

system to be developed should support

deposit related convenience services for

customers who visit the bank directly

customers who use ATMs and customers who

used the internet requirements may be

described as per the screen here the

design scope is set and the actors and

the ultimate user goals are identified

the primary actors are ATM customers

internet banking customers and bank

clerks and each goal depends on the role

of the primary actor for example the

goal of deposits is the goal of

customers visit

the bank with the money to deposit in

their accounts but it is not the goal of

internet banking customers in addition

the secondary actors are extracted

according to the goal of the primary

actor in the case of goal account

transfer the secondary actor other bank

system has been extracted because it

includes the account transfer to another

bank and the design scope sets the

system boundary for example the design

scope of a system that supports

depositor services to ATM customers will

be a deposit service system that

includes multiple ATMs we will continue

to map the goals defined in the example

requirements to the use cases 1 to 1 and

express the relationship between the

actors and use cases in the use case

diagram the figure on the screen is the

use case diagram of the UML in the

figure we use different notation to

distinguish the primary actor from the

secondary actor in UML an actor can be

represented as a class because it is an

object with behavior in the case of

external systems that is secondary

actors they can also be expressed in UML

classes of course you can mark it as a

bar shaped person the first step is to

refine the use case diagram in initial

use case diagram of the diagram some use

cases may have common behaviors to the

inside these common behaviors can be

separated into sub use cases the table

on the screen shows the process of

extracting common behaviors from the use

cases shown in the initial use case

diagram for example use case balance

inquiry and transaction history inquiry

for internet banking users commonly

require an account inquiry in addition

balance inquiry transaction history

inquiry and account transfer use cases

can have login logout for internet

security access in common the results of

these tables and the initial use case

diagrams can be represented as refined

use case diagrams as shown in figure

based on the results of the previous

table

the relationship between primary use

cases and sub use cases is represented

as includes in the refined use case

diagram this time to see the dynamic

behavior analysis let's develop a

sequence diagram for the use case of

deposit this example only introduces two

object lifecycle classes for convenience

the table shows how to assign

responsibilities related to objects

participating in an account opening

scenario there are two events there are

several participating objects which

define the responsibilities that each

event and participating object must

perform message passing between objects

follows the criteria described in the

table on the screen o indicates an

acceptable message sequence the diagram

on the screen is a sequence diagram

developed by applying the responsibility

assignment result and message exchange

principle table as there is an actor

called a bank clerk it is a sequence

diagram in which the participating

objects are listed on the x-axis and

which events occur between each object

and what behaviors are being performed

by which responsibility

[Music]

this time we will learn how to write a

requirements specification based on an

example written in accordance with the

industry standard ie EE the screen is

part of Bank A's software requirements

specification which contains the result

of analyzing functional requirements and

specifying process breakdowns functional

requirements include all the details

that a software developer needs to

design which describes how the input is

transformed into output because it is

the most important item in the

specification all the requirements must

be clear and verifiable each function

can be decomposed into several sub

functions in addition when describing

the functional aspects of the

development target system in the

specification you should select the

appropriate diagram based on the

application methodology for example when

developing using a structured technique

create a data flow diagram in the

object-oriented methodology create a use

case diagram and in the information

engineering methodology create process

decomposition diagram an example of the

screen describes a process decomposition

diagram by information engineering

methodology the next screen is the

definition and specification of the base

process or use case of the process

decomposition diagram we saw earlier IO

data systems for each function

identified with a function definition

for each process are identified and for

input it can be identified and defined

in the standardized forms that your

business uses in this input-output

specification process external interface

data not belonging to the development

scope is also defined and identified

[Music]

[Music]

[Music]