1-Introduction.pptx

Software

Requirement

Engineering

Administration

_{3 credit hour course} _{2 lectures a week} _Discipline

 _{Cell phones}  _{Cross talking}

Distribution

_{Mid term25%}

_{Final Term 50%}

_{Quiz 5%}

_{Assignments/ Class Activity 5%} _{Semester Project 15%}

Books

•_{Requirements Engineering: Processes and}

Techniques by Gorald Kotonya and Ian Sommerville

Course web link

https://sites.google.com/a/cs.uol.edu.pk/sref16/ [email protected]

What is a requirement?

 _{A statement of a system service or constraint}

_{It may range from a high-level abstract statement}

of a service or of a system constraint to a detailed mathematical functional specification.

_{Requirements may serve a dual function}

_{May be the basis for a bid for a contract -}

therefore must be open to interpretation;

_{May be the basis for the contract itself -}

therefore must be defined in detail;

_{Both these statements may be called}

What is Requirements

Engineering?

_{The process of establishing the services that the}

customer requires from a system and the constraints under which it operates and is developed.

_{The requirements themselves are the descriptions}

of the system services and constraints that are generated during the requirements engineering process.

What is Process?

•

_{A process is an organised set of activities}

which transforms inputs to outputs

•

_{Process descriptions encapsulate}

knowledge

and allow it to be

reused

•

Examples of process descriptions

– _{Cookery book}

– _{Procedures manual for a bank}

What is a requirements engineering

process?

• _{The structured set of activities involved in developing}

system requirements

• _{Process activities include requirements elicitation,}

requirements analysis and negotiation, requirements specification, requirements validation and

requirement management

• _{A complete process description should include} – _{what activities are carried out,}

– _{the structuring or scheduling of these activities,} – _{who is responsible for each activity,}

– _{the inputs and outputs to/ from the activity and}

Is there an ideal requirements engineering process?

• _{No - processes must be tailored to organisational needs} • _{Each organization tailored the process according to the}

type of systems it develops, its organizational culture

and the level of experience and ability of the people

involved in requirements engineering.

• _{To define a good requirements engineering process,}

organizations need to involve the people who are actually part of requirement engineering.

How much does requirements engineering cost?

• _{About 15% of system development costs}

• _{The requirement engineering cost depends on}

the type and size of the system being developed

• _{In some cases, the system requirements are not}

developed in detail; in others a formal specification may be produced.

Relative cost to correct a requirement

defect in different phases

What happens when the requirements are wrong?

• _{The system may be delivered late and costs}

more than originally expected

• _{The customer and end-user are not satisfied}

with the system. The may not use its facilities and may even decide to scrap it altogether

• _{The system may be unreliable in use, with}

regular system errors and crashes disrupting normal operation

• _{If the system continue in use, the cost of}

maintaining and evolving the system are usually very high.

What is a requirements document?

•

_{The formal statement of the system}

requirements for customer, end user and

software developers.

•

Depending on the organization, the

requirement document may have different

names such as

– _{Functional specification}

– _{The requirements definition}

What is the relationship between

requirements and design?

• _{Requirements are mostly concerned with the}

problem to be solved; design is concerned with the solution to the problem

• _{That is requirements engineering is about what}

has to be done; design is about how it should be done

• _{They should, ideally, be separate processes but}

in practice this is impossible.

• _{In reality, requirements engineering and design}

Reasons why requirement engineering and

design are interlaced activities?

• _{Systems are always installed in some environment, and there are}

always other systems in the environment. These other systems constraints the design of the system.

• _{For large systems, some architecture design is necessary to}

identify sub systems are their relationships. Requirements for these subsystems may then be specified.

• _{For reasons of budget, schedule or quality, an organization may}

wish to reuse some or all of existing software systems in the implementation of the new system. This constraints both the system requirements and the design.

• _{If a system has to be approved by an external regulator (e.g.}

aircraft), it may be necessary to use a standard ‘certified design’ which has been tested in the other systems.

What are system stakeholders?

•

_{Anyone affected in some way by the}

system and who have a direct or indirect

influence on the system requirements

•

The stakeholders include

– _{end-user of the system,} – _{customer of the system,}

– _{managers and others involved in the}

organizational processes influenced by the system,

– _{engineers responsible for the system}

Who is the Customer?

•_{A customer is an individual or organization who}

derives either direct or indirect benefit from a product.

•_{Software customers include those project stakeholders}

who request, pay for, select, specify, use, or receive the output generated by a software product.

•_{They provide the high-level concept for the product}

and the business rationale for launching it, establishing the Product Vision and Product Scope

What is Business Requirement

•_{Business requirements describe the business objectives that}

the customer, company, or other stakeholders want to achieve.

•_{Business requirements establish a guiding framework for the}

rest of the project.

•_{All other product features and requirements ought to align}

with satisfying the business requirements.

•_{Business opportunities, business objectives, success metrics,}

and a vision statement make up the business requirements.

•_{However, business requirements don't provide sufficient}

User Requirements

•

_{User requirements should come from people}

who will actually use the product, directly or

indirectly.

•

_{These users (often called}

_{end users}

_{) therefore}

constitute another kind of customer.

•

_{Users can describe the tasks they need to}

perform with the product and the quality

characteristics they expect the product to

exhibit.

System requirements

•

_{System requirements}

•_{setting out detailed descriptions of the system’s}

functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.

Functional requirements and

non Functional Requirements

• _{Functional requirements}

• _{specify the behaviors the product will exhibit under specific} conditions.

• _{They describe what the developers must implement to enable users} to accomplish their tasks (user requirements), thereby satisfying the business requirements.

• _{Functional requirements often are written in the form of the} traditional “shall” statements:

• _{“The Passenger shall be able to print boarding passes for all flight} segments for which he has checked in”

• _{Nonfunctional requirement}

• _{A description of a property or characteristic that a system must} exhibit or a constraint that it must respect.

• _{Constraint is a restriction that is imposed on the choices available to} the developer for the design and construction of a product.

Feature

•_{A feature consists of one or more logically related}

system capabilities that provide value to a user and are described by a set of functional requirements.

•_{Web browser bookmarks, spelling checkers,}

automatic virus signature updating in an anti-malware product are examples of features

•_{A feature can encompass multiple user}

requirements, each of which implies that certain functional requirements must be implemented to allow the user to perform the task described by each user requirement.

Relationships among features, user requirements, and functional requirements

Users of requirements

documents

•_{System customers}

• _{specify the requirements and read them to check they}

meet their needs

•_{Project managers}

• _{Use the requirements document to plan a bid for system}

and to plan the system development process

•_{System engineers}

• _{Use the requirements to understand the system being}

developed

•_{System test engineers}

• _{Use the requirements to develop validation tests for the}

system

•_{System maintenance engineers}

Sign-Of

•_{Reaching agreement on the requirements for the}

product to be built is at the core of the customer-developer partnership

•_{Many organizations use the concept of signing off on the}

requirements document as the mark of customer approval of those requirements

•_{Sign-off ritual is the concept of establishing a baseline of}

Factors influencing requirements

• _{The personal goals of individuals within an organisation}

• _{Each group of stakeholders have different goals. They will try to} influence the requirements so that their goals are met, without necessarily taking the goals of the other stakeholders into account • _{Personality and status of stakeholders}

• _{If the end user has managerial support then their requirements} will probably be accepted

• _{If the end user has an aggressive personality , the engineers may} agree to accept their requirements simply to get rid of them

• _{The degree of political influence of stakeholders within an}

organisation

• _{People try to influence system requirements, so that they can} maintain or increase their own political influence in the

organization.

• _{If a budget information system is planning in a university, both} administration and academic departments are likely to propose requirements which give them more power

Requirements risks

• _{Insufficient User Involvement}

• _{Customers often don't understand why it is so essential to work hard on} gathering requirements and assuring their quality

• _{Developers might not emphasize user involvement, either because} working with users isn't as much fun as writing code or because they think they already know what the users need

• _{In some cases, it's difficult to gain access to people who will actually use} the product, and user surrogates don't always understand what users really need

• _{Insufficient user involvement leads to late-breaking requirements that} delay project completion

Requirements risks

• _{Creeping User Requirements}

• _{As requirements evolve and grow during development, projects often}

exceed their planned schedules and budgets

• _{To manage scope creep, begin with a clear statement of the project's}

business objectives, strategic vision, scope, limitations, success criteria, and expected product usage.

• _{Evaluate all proposed new features or requirements changes against}

Requirements risks

•_{Ambiguous Requirements}

• _{a reader can interpret a requirement statement in several ways} • _{Ambiguity also results from imprecise and insufficiently detailed}

requirements that force developers to fill in the blanks.

• _{Ambiguous requirements result in wasted time when developers}

implement a solution for the wrong problem.

• _{Testers who expect the product to behave differently from what}

Requirements risks

•_{Minimal Specification}

• _{Sometimes marketing staff or managers are tempted to}

create a limited specification

• _{They expect the developers to expand the spec while the}

project progresses

• _{This might work for a tightly integrated team that's building}

a small system

• _{In most cases, though, it frustrates the developers and}