Tuesday, 6 March 2018

Software Engineering | SE Lecture 4

>>>>> Download Link Here <<<<<


You can download the slides from the link given above.
In this lecture, we will focus on following points:


  • Requirement Engineering
  • Some topics from previous lectures

----------------------------------------------------------------------------------------------


In this slide:


Introduction to
Requirement Engineering - 3
By Abdul Razaq Ali
Lecturer, PUCIT
In Today’s Lecture
Spiral Model
Agile Process
Requirement Engineering
Spiral Model (again)
The spiral model is similar to the incremental model, with more emphasis placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed.

Link: http://istqbexamcertification.com/what-is-spiral-model-advantages-disadvantages-and-when-to-use-it/
Agile Process
“Agile Development” is an umbrella term for several iterative and incremental software development methodologies. The most popular agile methodologies include 
Extreme Programming (XP)
Scrum

An Agile Process implies a
A light Process – prefers a small set of activities and artifacts
An Adaptive Process – emphasizes on handling changing requirements
Software Requirements -1
Requirements are…a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute
The IEEE Standard Glossary of Software Engineering Terminology (1990) defines a requirement as:
A condition or capability needed by a user to solve a problem or achieve an objective.
A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.

Software Requirements -2
A complete description of what the software system will do without describing how it will do it is represented by the software requirements
Software requirements are complete specification of the desired external behavior of the software system to be built
Software Requirements -3
Software requirements can be:
Part of the bid of contract
The contract itself
Part of the technical document, which describes a product

Software requirements can be:
Abstract statements of services and/or constraints Detailed mathematical functions
What are NOT Requirements
Requirements do not include:
Design or Implementation details (other than known constraints)
Project planning information, or testing information. 
Development environment requirements, schedule or budget limitations
Need for a tutorial to help new users get up to speed, or requirements for releasing a product and moving it into the support environment.

These are project requirements but not product requirements. Separate such items from the requirements so that the requirements activities can focus on understanding what the team intends to build.
Levels of Requirements
Software Requirements Engineering
Requirements engineering -is the process which enables us to systematically determine the requirements of a software product

Requirements engineering -refers to the process of formulating, documenting and maintaining software requirements
A principal -A Domain
Requirement Development
Requirements development can be further subdivided into elicitation, analysis, specification, and validation
Identifying the product's expected user classes
Eliciting needs from individuals who represent each user class
Understanding user tasks and goals and the business objectives with which those tasks align
Analyzing the information received from users to distinguish their task goals from functional requirements, nonfunctional requirements, business rules, suggested solutions, and extraneous information
Negotiating implementation priorities
Translating the collected user needs into written requirements specifications and models
Reviewing the documented requirements to ensure a common understanding of the users' stated requirements and to correct any problems before the development group accepts them
Requirements Development Process
Requirements Management
Defining the requirements baseline (a snapshot in time representing the currently agreed-upon body of requirements for a specific release)
Reviewing proposed requirements changes and evaluating the likely impact of each change before approving it
Incorporating approved requirements changes into the project in a controlled way
Keeping project plans current with the requirements
Negotiating new commitments based on the estimated impact of requirements changes
Tracing individual requirements to their corresponding designs, source code, and test cases
Tracking requirements status and change activity throughout the project
Highlights of today’s lecture
Agile Process (Extreme Programming, Scrum)
Requirement Engineering
Book Reading
Roger S. Pressman  “Software Engineering- A practitioner’s approach”, 7th Ed. 
5.1 

Questions?

No comments :

Post a Comment