Software

Ch 2 requirement engineering.

(Refer book for full answers)

CORE PRINCIPLE OF
SOFTWARE
ENGINEERING
PRACTICE.
Communication practices
▪ Listen
▪ Prepare before you communicate
▪ Someone should facilitate the communication
▪ Face to face communication is best
▪ Take a note
▪ Callaborate with the customer
▪ Stay focuesd
Planning practices

▪ Understand the project scope

▪ Involve the customer in the planning activity
▪ Recognize that planning is iterative ( run with the plan )
▪ estimate based on what you know.(guess)
▪ Consider risk as you define plan
▪ Be realistic
▪ Define how quality will be achieved
▪ Define how you'll accommodate( accept ) changes
▪ Track & make adjustment as required
Modelling practices
▪ The primary goal of the software team is to build a software, not create a model.
▪ Don't create more models than you need.
▪ strive (Aim) to produce the simplest model that will describe the problem of a software.
▪ Build models in a way that makes them agreeable to change.
▪ Be able to state an explicit purpose for each model that is created.(why we create the model )
▪ Try to build useful model but forget about to build the perfect model.
▪ Get a feedback as soon as possible.
Analysis Modelling practices

▪ The information domain of the problem must be represented and understood

▪ Represents software functions.
▪ They represent software behavior
▪ The analyst tasks should be moved from essential information
toward implementation detail.
Design modeling practices.
▪ Design must be trackable to the analysis model.
▪ focus on the design of data as it is as important as a design.
▪ Always consider architecture
▪ User interface design should be tuned to the need of the end user.
▪ Interface must be designed
▪ Design representation should be easy understood
▪ Components should be loosely coupled to each other's.
Coding principles.
▪ Select the proper data structure.
▪ Understand the software architecture.
▪ Keep conditional logic, a simple as possible.
▪ create easily tested nested loops.
▪ Write a code in self and documenting.
▪ Create a visual layout.
What is software deployment? &
principle

▪ Software deployment includes all of the steps, processes, and activities that are required to make a software
system or update available to its intended users. Today, most IT organizations and software developers deploy
software updates, patches and new applications with a combination of manual and automated processes. Some of
the most common activities of software deployment include software release, installation, testing, deployment, and
performance monitoring
 Principles of software development.
▪ Customer expectations for the software must be managed.
▪ A complete delivery package should be assembled and tested.
▪ Support regime(Technical support) must be established before the software is delivered.
▪ Appropriate instructions material to must be provided to the end user.(training aids and guidelines)
▪ buggy software should be fixed first to deliver later.
 Requirements engineering (RE) refers to the
What is the
▪
process of defining, documenting, and maintaining
requirements in the engineering design process.
requirement Requirement engineering provides the appropriate
mechanism to understand what the customer
engineering desires, analyzing the need, and assessing
feasibility, negotiating a reasonable solution,
and its specifying the solution clearly, validating the
specifications and managing the requirements as
principal? they are transformed into a working system.
requirement engineering principal
▪ The requirement should be unmistakable
▪ Requirement should be testable.
▪ Requirement should be cleared.
▪ Requirement should be understandable.
▪ Requirement should be feasible.(Realistic possible. )
▪ Requirement should be consistent.(compatible)
Activities involved in requirement
engineering
▪ Inception
▪ Elicitation
▪ Elaboration
▪ Negotiation
▪ Specification
▪ Validation
▪ Requirements management
Inception
▪ They understand basic detail aim goal of the
project and find out the solution.
▪ They identify stakeholder and who want the
solution.
▪ They understand the nature of solution.
▪ Enhance collaboration between customer and
developer
Elicitation
▪ Problem of scope (the unnecessary technical
detail)
▪ Problem of understanding(skip detail)
▪ Problem of volatility(change in requirement)
Elaboration
▪ Expand Inception Elicitation
▪ It is the main task is developing model and
prototype of software using functions, features
and constraints of the software using different
tool.
Negotiation
▪ Limited Time
▪ Limited Money
▪ Clash of requirement
▪ Un real requirement
▪ Win win
Specification
▪ Functional Requirements:
These describe what the software system should do. They specify the
functionality that the system must provide, such as input validation, data
storage, and user interface.

▪ Non-Functional Requirements:
these describe how well the software system should do it

They specify the quality attributes of the system, such as performance,

reliability, usability, and security

▪ Acceptance Criteria:(when it completed)

▪ Constraints(Limitation and restriction)
Functional
Requirements:(how
it work .e.g. car)
▪ These describe what the software system should do. They specify the functionality that the system
must provide, such as input validation, data storage, and user interface.

▪ Types of Functional Requirements

▪ Here are the most common functional requirement types:

▪ Transaction Handling

▪ Business Rules

▪ Certification Requirements

▪ Here, are the pros/advantages of creating a typical functional requirement document-

▪ Helps you to check whether the application is providing all the functionalities that were mentioned
in the functional requirement of that application

▪ A functional requirement document helps you to define the functionality of a system or one of its
subsystems.
Non-Functional
Requirements

▪ These are the quality constraints that the system must

satisfy according to the project contract. The priority or
extent to which these factors are implemented varies
from one project to another. They are also called non-
behavioral requirements. They deal with issues like:
▪ Security
▪ Storage
▪ Configuration
▪ Cost
▪ Scalability/Flexibility
▪ Performance
Validation
▪ Error and debugging
▪ Quality insurance.
▪ Check any missing information.
▪ Add any additional information.
Requirements
management
▪ The requirement management process is the process
of managing changing requirements during the
requirements engineering process and system
development where the new requirements emerge as a
system is being developed and after it has gone into
use. During this process, one must keep track of
individual requirements and maintain links between
dependent requirements so that one can assess the
impact of requirements changes along with
establishing a formal process for making change
proposals and linking these to system requirements.
What is requirement elicitation?
▪ Requirements elicitation is the process of gathering and defining the requirements for a software system. The goal of requirements
elicitation is to ensure that the software development process is based on a clear and comprehensive understanding of the
customer’s needs and requirements. This article focuses on discussing Requirement Elicitation in detail.
Requirements Elicitation Methods:
1. Interviews
▪ Objective of conducting an interview is to understand the customer’s expectations from the software.
It is impossible to interview every stakeholder hence representatives from groups are selected based on their expertise and
credibility. Interviews maybe be open-ended or structured.

2. Brainstorming Sessions
▪ It is a group technique

▪ It is intended to generate lots of new ideas hence providing a platform to share views

▪ A highly trained facilitator is required to handle group bias and group conflicts.

▪ Every idea is documented so that everyone can see it.

▪ Finally, a document is prepared which consists of the list of requirements and their priority if possible.
Requirements modeling
▪ The technique of modeling requirements and solutions as they change through collaborative work and cooperation is
known as Requirements Modeling. You may ensure that your team satisfies the stakeholders’ exact requirements by
employing this approach of cross-functional, self-organizing teams
The Requirements Modeling process involves three main activities:
▪ Analysis: Once the Requirements have been collected, they need to be analyzed to see if they are complete, consistent, and clear. Any
inconsistencies or ambiguities should be resolved at this stage.

▪ Documentation: The Requirements should be documented in a clear and concise way. This will ensure that everyone understands the
Requirements and can refer back to them if needed.

▪ Management: Once the Requirements have been collected and documented, they need to be managed throughout the project. This includes
keeping track of changes to Requirements, making sure everyone is aware of these changes, and ensuring that the requirements are still being
met.
Requirement negotiation
▪ This phase emphasizes discussion and exchanging conversation on what is needed and what is to be eliminated. In the negotiation
phase, negotiation is between the developer and the customer, and they dwell on how to go about the project with limited busi ness
resources. Customers are asked to prioritize the requirements and make guesstimates on the conflicts that may arise along wit h it.
Risks of all the requirements are taken into consideration and negotiated in a way where the customer and developer are both
satisfied with reference to the further implementation.

The following are discussed in the negotiation phase:

▪ Availability of Resources.

▪ Delivery Time.

▪ Scope of requirements.

▪ Project Cost.

▪ Estimations on development.
Software Requirements Specification
(SRS)

▪ Define
▪ Why imp

▪ Characteristics
▪ Consistency(requirement confit)
▪ Completeness(proper doc of system)
▪ Unambiguousness(each req have only one meaning )
▪ Ranking of imp and stability(thinks should be present in software)
▪ Modifiable(srs can be mod)
▪ Verify
▪ Traceability (know the origin of req)