Machine Translated by Google

University of Ngaoundéré
University Institute of Technology (IUT)
Info Genius 2, GLO
UE: Fundamentals of Software Engineering (IFT 322)

Course objective : Prepare students to master the

Basic software engineering techniques and concepts.
At the end of this course, you will be able to:
• use computer techniques and engineering principles
for software development projects.
• design, develop and test software systems and applications for
industry, business and individual needs.

• apply proven methods and good practices to

produce quality software in strict compliance with budget and
calendar.
• extract, analyze and specify needs through good
productivity of work with different stakeholders and effective communication,
respecting ethics and rules
software engineering professionals .

Course Plan :
Chapter 1 : Introduction to Software Engineering
Chapter 2 : Software project planning, analysis and specifications
needs
Chapter 3 : Software Design
Chapter 4 : Implementation and testing
Chapter 5 : Maintenance and Project Management

Bibliographic references :

1
Machine Translated by Google

Chapter 2: Analysis, specifications of needs and

Planning a software project

This chapter presents the bases for producing the specifications using
engineering mechanisms applied to requirements gathering. He explains how
understand what customers want, how to analyze and validate their needs and finally
produce specifications. The chapter also develops a set of activities
related to software project planning. Software project planning also affects
cost estimate and project schedule.

At the end of this chapter, you should be able to:

• Define the following terms: requirements engineering, requirements, planning
softwares
• Describe the processes adopted in requirements engineering
• Demonstrate the requirements determination process
• Explain the concept of project management and its four important elements
(people, products, processes and project)
• Describe the concept of project management based on the research of estimation
project costs
• Use the guided estimation steps to obtain the project cost.

Key terms :

Requirement : A requirement is a characteristic of the system or a description of

something the system is capable of doing to fulfill the system's purpose.
Requirements engineering : Requirements engineering is the systematic use
proven principles, techniques and linguistic tools for analysis,
cost-effective documentation, and assessment of user needs and specifications of the
external behavior of a current system to satisfy user needs.
Software Project Estimation : Software project estimation is the process
estimation of the different resources necessary to carry out a project.

20
Machine Translated by Google

I- Requirements engineering
In this activity, the definition of Need and requirements engineering is presented. He
develops the process adopted in requirements engineering which will lead to obtaining the
system/software specifications.

I.1- Requirement

A requirement is a characteristic of the system or a description of something

that the system is capable of doing to fulfill the system's objective.
Requirements describe the what of a system, not the how. The engineering of
requirements produces a large document, written in natural language, and contains a
description of what the system will do without describing how it will do it. It provides the
appropriate mechanism to understand what the customer wants, analyze the need,
assessing feasibility, negotiating a reasonable solution, specifying the
unambiguous solution, specification validation and requirements management.
Requirements engineering is the systematic use of proven principles,
linguistic techniques and tools for cost-effective analysis, documentation, and
user needs assessment course and behavior specifications
external of a system to satisfy user needs. It can be defined
as a discipline, which responds to the requirements of objects throughout a process
development system.
As in Figure 2.1, the input to requirements engineering is the problem statement
prepared by the customer. The output of the Requirements Engineering (RE) process is a
specification of system requirements called the definition and description of
the requirement (RDD). The system specifications therefore constitute the basis for the
design of software solutions.

Figure 2.1: The Requirements Gathering Process

21
Machine Translated by Google

Requirements are classified into two types:

a) Functional requirements
•
They define factors, such as I/O formats, storage structure,
computing capabilities, timing and synchronization.
• Are those which relate directly to the operation of the system.
• These are the aspects of the system that the customer is most likely to recognize.
b) non-functional requirements
•
They define the properties or qualities of a product, as well as the constraints/
restrictions imposed on the system.
•
They include ease of use, efficiency, performance, space,
reliability, portability, etc.

I.2- Requirements engineering process

Figure 2.2 illustrates the steps in the requirements engineering process. The engineering of
requirements consists of the following processes:

Figure 2.2 : Steps in the requirements engineering process

I.3- Collection of requirements

It is a process of communication between concerned and affected parties in the
problem situation. Sources of information include customers, users
end users, primary and secondary users and stakeholders.
Ask the customer, users, and others what the goals of the system or a
product are, what is to be accomplished, how the system or product fits into the
business needs, and finally, how the system or product should be used
daily. The collection tools are meetings, interviews,
videoconferencing, e-mails, and the results of the study of existing documents and facts.
More than 90% to 95% of the collection is expected to be completed at the opening stage, while
that the remaining 5% can be collected during the development life cycle.

22
Machine Translated by Google

Requirements gathering is a process fraught with difficulties:

Scope issues : The system boundary is not well defined. Customers /
users may specify unnecessary technical details that may create confusion
confusion, rather than clarifying the overall objectives of the system.
Understanding problems : Customers/users are not completely
sure of what is needed, poor understanding of capabilities and limitations
of their IT environment, do not have a complete understanding of the domain
of the problem, have difficulty communicating the needs of the systems engineer, fail to
information that we believe to be obvious, forget to specify the requirements that come into play
conflict with the needs of other customers/users, or specify requirements that
are ambiguous or unverifiable.
Volatility issues : Requirements change over time.

I-4 Requirements analysis and modeling

Once the requirements have been collected, the work products mentioned
previously constitute the basis of the needs analysis. The analysis categorizes the
requirements and organizes them into related subsets; explores each requirement in relation
with the others ; examines the requirements for validity, consistency, omissions,
of ambiguity; Feasibility requirements and rank based on customer needs/
users.
• Validity confirms its relevance to the goals and objectives and always confirms
that it is not inconsistent with other requirements, but supports
others if necessary.

• Feasibility ensures that the necessary inputs are available without bias or errors,
and technology support is possible to execute the requirement as a
solution.

• In another point, the analysis attempts to find for each requirement, its
functionality, features, facilities and the need for these in
different conditions and constraints.

• Functionality states how to achieve the objective of the requirement.

• Features describe the attributes of the functionality, and
• Equipment providing its service, administration and communication with others
systems.

23
Machine Translated by Google

I.5- Explanation and analysis process model

A model of the generic process of explication and analysis is illustrated in Figure
2.3. The process activities are as follows:

Figure 2.3 : Explanation and analysis process model

Understanding of the domain : Analysts must develop their understanding of the
domaine d’application.
Requirements Collection : This is the process of interacting with stakeholders
into the system to discover their needs. Domain understanding
develops further during this activity.
Classification : This activity takes the unstructured collection of requirements and organizes them
in coherent clusters.
Conflict resolution : When multiple actors are involved, the requirements will be
in conflict. This activity focuses on the results and resolution of these conflicts.
Prioritization : some requirements will be more important than others in terms of
priorities. This step involves interaction with stakeholders to discover
the most important requirements.
Requirements Verification : Requirements are checked to find out if they are
complete, coherent, and in accordance with what stakeholders really want from
system.
Requirements Documentation (Specification)
Requirements documentation is written after requirements collection and analysis.
This is the way to represent the requirements in a consistent format. The document

24
Machine Translated by Google

constituted is the specifications (which is called Software Requirement

Specifications (SRS)).
SRS is a specification for a particular software product, program or
set of programs that perform certain functions in an environment
specific.
Requirements should be written so that they are meaningful, not only to
customers, but also for the designers of the development team. The document
needs definition describes what the customer would like to have:
• The outline of the general objective of the system. References to other systems
Related terms and abbreviations that may be useful are included
• Description of the background and development objectives of the system
• The new approach proposed to solve the problem by the customer, the case
applicable. Describe a description of the approach.
• The detailed characteristics of the proposed system, the definition of the limits of the
system and interfaces through it. The system functions are also
explained. Additionally, we include a complete list of elements and classes
data and their characteristics are included.
• The environment in which the system will operate. Include requirements for
support, security and privacy and hardware or software constraints
special conditions must be specified.
A specification can be a written document, a graphic model, a model
formal mathematics, a collection of usage scenarios, a prototype, or any
combination of these. Some suggest that a standard model should be
developed and used for a system specification, arguing that this leads
to requirements that are presented in a coherent manner and therefore more
understandable.

I.7- Validation of requirements

This is a manual process that involves multiple readers at once: customer and staff
to check the requirements document for anomalies and omissions. Requirements validation
reviews the specification to ensure that all requirements
of the system have been declared unambiguously; that inconsistencies, omissions and
errors were detected and corrected; and that the work products are compliant
to the standards established for the process, the project, and the product.

25
Machine Translated by Google

A review or validation of requirements can be formal or informal

• Informal reviews simply involve discussions about requirements
with as many system stakeholders as possible. Many problems can
be detected simply by talking about the system to stakeholders before
make a commitment to a formal review.
• In a formal requirements review, the development team should work with
the customer. The review team must verify the consistency of each requirement and must verify
the requirements as a whole. Formal technical review is the mechanism for
validation of primary requirements.

I.8- Requirements management

Requirements define the capability the software solution must provide and the results
expected which should result from its application to business problems. In order to
generate such requirements, a systematic approach is necessary, through a
formal management process called requirements management.
Requirements management is defined as a systematic approach to elicit,
organize and document system requirements, and a process that establishes and
maintains agreement between the client and the project team on evolving project requirements
system. It is a set of activities that help the project team to identify,
control and track requirements and changes to requirements at all
as the project progresses.
Requirements management starts with identification. Each requirement is assigned
a unique identifier which could take the form:
<Condition type> <requirement #>
Where the condition type takes values such that condition F = functional, condition
D = data, B = behavior requirement, I = interface requirement, and P = power
required.

Conclusion

The important and difficult part of building software is deciding precisely what to build and
establishing the detailed technical requirements. These
Requirements are identified by obtaining information from the client. The requirements are
analyzed to assess their clarity, completeness and consistency. Finally, the requirements of
system are managed to ensure that changes are properly controlled.

26
Machine Translated by Google

Assessment

1. What are long-term requirements?

2. Explain the process of determining requirements for a system based on a
software.

3. Discuss the meaning and use of requirements engineering. What are the
problems in formulating requirements?
4. What are the crucial steps in requirements engineering? Chat with help
of a diagram.
5. Explain the importance of needs. How many types of requirements are possible and
Why ?
6. What is requirements gathering? Discuss both techniques in detail.

27