Software Engineering - PowerPoint PPT Presentation

Loading...

PPT – Software Engineering PowerPoint presentation | free to download - id: 7ce036-Nzc2M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Software Engineering

Description:

Originally shared for: mashhoood.webs.com Lecture 7 Software Engineering Saeed Akhtar The University of Lahore – PowerPoint PPT presentation

Number of Views:58
Avg rating:3.0/5.0
Slides: 20
Provided by: freew173
Learn more at: http://memberfiles.freewebs.com
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Software Engineering


1
Originally shared for mashhoood.webs.com
Lecture 7
  • Software Engineering

Saeed Akhtar
The University of Lahore
2
Requirement Engineering
3
Requirement Engineering
  • RE helps software engineer to better understand
    the problem they will work to solve
  • Participant Software Engineers, managers,
    customers and end users
  • RE is a software engineering action that begin
    during the communication activity and continues
    into the modeling activity

4
RE Provides the appropriate mechanism for
  • Understanding what the customer want
  • Analyzing need
  • Assessing feasibility
  • Negotiating a reasonable solution
  • Specifying a solution unambiguously
  • Validating the specification
  • Managing the requirement as they are transformed
    into an operational system

5
Requirement Engineering Task
  • Inception
  • Elicitation
  • Elaboration
  • Negotiation
  • Specification
  • Validation
  • Requirement Management

6
Requirement Engineering Tasks
  • InceptionEstablish a basic understanding of the
    problem and the nature of the solution.
  • ElicitationDraw out the requirements from
    stakeholders.
  • ElaborationCreate an analysis model that
    represents information, functional, and
    behavioral aspects of the requirements.
  • NegotiationAgree on a deliverable system that is
    realistic for developers and customers.
  • SpecificationDescribe the requirements formally
    or informally.
  • ValidationReview the requirement specification
    for errors, ambiguities, omissions, and
    conflicts.
  • Requirements managementManage changing
    requirements.

7
Inception
  • Ask a set of questions that establish
  • basic understanding of the problem
  • the people who want a solution
  • the nature of the solution that is desired, and
  • the effectiveness of preliminary communication
    and collaboration between the customer and the
    developer

8
Inception Contd
  • Inception process
  • Identify stakeholders
  • who else do you think I should talk to?
  • Recognize multiple points of view
  • Work toward collaboration
  • the effectiveness of preliminary communication
    and collaboration between the customer and the
    developer
  • Asking The first questions
  • Who is behind the request for this work?
  • Who will use the solution?
  • What will be the economic benefit of a successful
    solution
  • Is there another source for the solution that you
    need?

9
Elicitation
  • It certainly simple enough, but
  • Why difficult
  • Problem of Scope
  • The boundary of the system is ill-defined
  • Problem of Understanding
  • The customer/users are not completely sure of
    what is needed
  • Problem of volatility
  • The requirement change over time
  • To help overcame these problem, requirement
    engineers ,must approach the requirement
    gathering activity in an organized manner

10
Elicitation Process Guideline
  • meetings are conducted and attended by both
    software engineers and customers
  • rules for preparation and participation are
    established
  • an agenda is suggested
  • a "facilitator" (can be a customer, a developer,
    or an outsider) controls the meeting
  • a "definition mechanism" (can be work sheets,
    flip charts, or wall stickers or an electronic
    bulletin board, chat room or virtual forum) is
    used
  • the goal is
  • to identify the problem
  • propose elements of the solution
  • negotiate different approaches, and
  • specify a preliminary set of solution requirements

11
Quality Function Deployment
  • Is a technique that translate the need of the
    customer into technical requirement for software.
  • QFD emphasize an understanding of what is
    valuable to the customer and then deploys these
    values throughout the engineering process
  • QFD identifies three types of requirement
  • Normal Requirement
  • Expected requirement
  • Exciting requirement

12
Elaboration
  • Expand requirement into analysis model
  • Elements of the analysis model
  • Scenario-based elements
  • Functionalprocessing narratives for software
    functions
  • Use-casedescriptions of the interaction between
    an actor and the system
  • Class-based elements
  • Implied by scenarios
  • Behavioral elements
  • State diagram
  • Flow-oriented elements
  • Data flow diagram

13
Negotiation
  • Agree on a deliverable system that is realistic
    for developers and customers
  • SW team other project stakeholders negotiate
    the priority, availability, and cost of each
    requirement
  • The Process are
  • Identify the key stakeholders
  • These are the people who will be involved in the
    negotiation
  • Determine each of the stakeholders win
    conditions
  • Win conditions are not always obvious
  • Negotiate
  • Work toward a set of requirements that lead to
    win-win

14
Specification
  • Final work product produced by requirement
    engineer.
  • Can be any one (or more) of the following
  • A written document
  • A set of models
  • A formal mathematical
  • A collection of user scenarios (use-cases)
  • A prototype

15
Validation
  • examine the specification to ensure that SW
    requirement is
  • not ambiguous, consistent, error free etc
  • A review mechanism that looks for
  • errors in content or interpretation
  • areas where clarification may be required
  • missing information
  • inconsistencies (a major problem when large
    products or systems are engineered)
  • conflicting or unrealistic (unachievable)
    requirements.

16
Validation Contd
  • A review of the analysis model addresses the
    following question
  • Is each requirement consistent with the overall
    objective for the system/product?
  • Have all requirements been specified at the
    proper level of abstraction? That is, do some
    requirements provide a level of technical detail
    that is inappropriate at this stage?
  • Is the requirement really necessary or does it
    represent an add-on feature that may not be
    essential to the objective of the system?
  • Is each requirement bounded and unambiguous?
  • Does each requirement have attribution? That is,
    is a source (generally, a specific individual)
    noted for each requirement?
  • Do any requirements conflict with other
    requirements?

17
Validation Contd
  • Is each requirement achievable in the technical
    environment that will house the system or
    product?
  • Is each requirement testable, once implemented?
  • Does the requirements model properly reflect the
    information, function and behavior of the system
    to be built.
  • Has the requirements model been partitioned in
    a way that exposes progressively more detailed
    information about the system.
  • Have requirements patterns been used to simplify
    the requirements model. Have all patterns been
    properly validated? Are all patterns consistent
    with customer requirements?

18
The problems is not that there are problems. The
problem is expecting otherwise and thinking that
having problems is a problem Theodore Rubin
19
Thank You
About PowerShow.com