Scribd
Upload
10 views21 pages

Se ch2 Part 1

The document discusses requirement engineering including its principles, activities, and types of requirements. It explains that requirement engineering is the process of defining, documenting, and maintaining requirements. The key activities are inception, elicitation, elaboration, negotiation, specification, and validation.

Uploaded by

Jack Chetty (Lion gaming)
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
10 views21 pages

Se ch2 Part 1

The document discusses requirement engineering including its principles, activities, and types of requirements. It explains that requirement engineering is the process of defining, documenting, and maintaining requirements. The key activities are inception, elicitation, elaboration, negotiation, specification, and validation.

Uploaded by

Jack Chetty (Lion gaming)
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 21

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
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.

Non-Functional Requirements

These are the quality constraints that the system must satisfy according to the project contract. The priority or extent to w hich 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.

You might also like