Requirements engineering
This presentation is the property of its rightful owner.
Sponsored Links
1 / 40

REQUIREMENTS ENGINEERING PowerPoint PPT Presentation


  • 161 Views
  • Uploaded on
  • Presentation posted in: General

REQUIREMENTS ENGINEERING. What is a requirement?. Descriptions of the services provided by the system and its operational constraints. Reflects the needs of customers for a system. May be… A high level, abstract statement of a service that the system should provide A constraint on the system

Download Presentation

REQUIREMENTS ENGINEERING

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


REQUIREMENTSENGINEERING


What is a requirement?

  • Descriptions of the services provided by the system and its operational constraints.

  • Reflects the needs of customers for a system.

  • May be…

    • A high level, abstract statement of a service that the system should provide

    • A constraint on the system

    • A detailed formal definiton of a system function.


Requirements engineering

  • The process of finding out, analysing, documenting and checking these services and constraints.


Types of requirements

  • User requirements:

    • high-level abstract requirements

    • Statements of what services the system is expected to provide and the constraints under which it must operate.

  • System requirements:

    • The detailed description of what the system should do

    • Set out the system’s func., services and operational constraints in detail.


Types of requirements cont.

  • User requirements may be expanded into several system requirements by adding detail, explaining the services and functions.

  • Requirements should be written at different levels of detail because of different readers.


Functional and nonfunctional requirements

  • Functional requirements

    • Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.

  • Non-functional requirements

    • constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

  • Domain requirements

    • Requirements that come from the application domain of the system and that reflect characteristics of that domain.


Functional requirements

  • Describe the system function in detail, its input and outputs, exceptions etc.

  • Depends on…

    • The type of software

    • The expected users of the software

  • The specification of the functional requirements should be complete and consistent.


Nonfunctional requirements

  • May relate to reliability, response time and store occupancy.

  • Constraints are I/O device capability, system representations, etc.

  • May specify performance security and availability. So more critical than individual functional requirements.

  • Failing to meet can mean the whole system is unusable.


Types of nonfunctional requirements

  • Product req. Specify product behavior

    • Performance, reliability, portability, usability

  • Organisational req.

    • Process standards, implementation, delivery

  • External req.

    • Interoperability, legislative, ethical


Examples

  • Functional requirement:

    • “The customer must place an order within two minutes of registering.”

  • Nonfunctional requirement:

    • “The customer must be able to access their account 24 hours a day, seven days a week.”


Domain requirements

  • Derived from the application domain and describe system characteristics and features that reflect the domain.

  • Domain requirements maybe new functional requirements, constraints on existing requirements or define specific computations.

  • If domain requirements are not satisfied, the system may be unworkable.


Domain requirementsexample

  • Tolerance level of landing gear on an aircraft (different on dirt, asphalt, water), or what happens to fiber optics line in case of sever weather during winter Olympics (Only domain-area experts know)


Domain requirements problems

  • Understandability

    • Requirements are expressed in the language of the application domain;

    • This is often not understood by software engineers developing the system.

  • Implicitness

    • Domain specialists understand the area so well that they do not think of making the domain requirements explicit.


User requirements

  • Should describe the functional and nonfunctional requirements.

  • Should only specify the external behavior of the system.

  • System design characteristics, software jargon, structuredor formal notations, system implementation should be excluded.

  • Should be written in simple language.


Guidelines for writing requirements

  • Invent a standard format and use it for all requirements.

  • Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements.

  • Use text highlighting to identify key parts of the requirement.

  • Avoid the use of computer jargon.


System requirements

  • Expanded version of user req.

  • Describe the external behavior of the system and its operational constraints.

  • Must not include how the system designed and implemented.


Problems with NL specification

  • Ambiguity

    • The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult.

  • Over-flexibility

    • The same thing may be said in a number of different ways in the specification.

  • Lack of modularisation

    • NL structures are inadequate to structure system requirements.


Structured language specifications

  • Limits the terminology that can be used and use templates to specify system req. System req. May be specified by:

    • Using forms

    • Using tables

    • Using graphical models


Form-based specifications

  • Definition of the function or entity.

  • Description of inputs and where they come from.

  • Description of outputs and where they go to.

  • Indication of other entities required.

  • Pre and post conditions (if appropriate).

  • The side effects (if any) of the function.


Form based specification example

ECLIPSE/Workstation/Tools/DE/FS/3.5.1

Function:Add node

Description:Adds a node to an existing design.

Inputs:Node type, Node Position

Outputs:Design identifier

Pre/Post conditions:

Other attributes:

Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1


Structured lang. specification cont.

  • By using formatted specification variability is reduced and req. are organised more efficiently.

  • When complex requirements are needed tables or graphical models can be used.

    • Use tables when there are a number of possible alternative situations.

    • Use graphical models when you need to show how state changes or describe a sequence of actions.


The requirements document

  • SRS (software requirement specification) is the official statement of what the system developers should implement

  • Includes both user requirements and detailed specification of the system requirements.


The requirements document cont.

  • Has a diverse set of users

    • the req. document has to be a compromise between communicating the requirement to customers, defining them in precise detail for developers and testers and including information about possible system evolution.

  • The level of detail depends on the type of system that is being developed and the development process used.

    • External contractor: very detailed

    • Iterative development process: less detailed


IEEE requirements standard

  • Defines a generic structure for a requirements document that must be instantiated for each specific system.

    • Introduction.

    • General description.

    • Specific requirements.

    • Appendices.

    • Index.


Feasibility studies

  • A feasibility study decides whether or not the proposed system is worthwhile.

  • Inputs: List of business requirements, system description, how the system improve business

  • Outputs: Answer of the question “Should we do this development?”


Elicitation and analysis

  • Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints.

  • STAKEHOLDER: End-users, managers, engineers involved in maintenance, domain experts, trade unions, etc.

  • Shortly; people affected by the system directly or indirectly.


Requirements discovery

  • The process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information.

  • This information comes from documentation, system stakeholders and the specifications of similar systems.


Registration.boun.edu.tr

  • Who are stakeholders?


Interviewing

  • In formal or informal interviewing, the Requirements Engineering team puts questions to stakeholders about the system that they use and the system to be developed.

  • There are two types of interview

    • Closed interviews where a pre-defined set of questions are answered.

    • Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.


Scenarios

  • Scenarios are real-life examples of how a system can be used.

  • They should include

    • A description of the starting situation;

    • A description of the normal flow of events;

    • A description of what can go wrong;

    • Information about other concurrent activities;

    • A description of the state when the scenario finishes.


Registration scenario


Use cases

  • Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself.

  • A set of use cases should describe all possible interactions with the system.

  • Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.


Add course

Drop course

Student

Consent Requests

Instructor

Course scheduling

Registration

Office

Registration use cases


RegsPage

Regs system

:

course

Instructor

Mypage

BOUNsystem

Cmpe 352

Ayse Basar Bener

Student

request

request

acquired

return

Add OK

Inform available

Add available

Add

Add

inform

confirm

Add CMPE 352


Ethnography

  • A social scientists spends a considerable time observing and analysing how people actually work.

  • Social and organisational factors of importance may be observed.

  • Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models.

  • Requirements that are derived from the way that people actually work rather than the way which process definitions suggest that they ought to work. Reality!!!

  • Requirements that are derived from cooperation and awareness of other people’s activities.


Requirements validation

  • Concerned to validate that the requirements define the system that the customer really wants.

  • Requirements error costs are high so validation is very important

    • Fixing a requirement error before completing project or delivering it is much more cheaper...


Requirements checking

  • Validity. Does the system provide the functions which best support the customer’s needs?

  • Consistency. Are there any requirements conflicts?

  • Completeness. Are all functions required by the customer included?

  • Realism. Can the requirements be implemented given available budget and technology

  • Verifiability. Can the requirements be checked?


Requirements management

  • Requirements management is the process of managing changing requirements during the requirements engineering process and system development.

  • Requirements are inevitably incomplete and inconsistent

    • There will be always requirements during the process as business needs change and a better understanding of the system is developed;

    • Different viewpoints have different requirements and these are often contradictory; Students do not want to take courses starting at 09.00am, Instructors do not want to come to school everyday.


Requirements change management

  • Should apply to all proposed changes to the requirements.

  • Principal stages

    • Problem analysis. Discuss requirements problem and propose change;

    • Change analysis and costing. Assess effects of change on other requirements;

    • Change implementation. Modify requirements document and other documents to reflect change.


References

  • Ian Sommerville, Software Engineering

  • http://www.requirementsauthority.com/functional-and-non-functional.html

  • http://en.wikipedia.org/wiki/Sequence_diagram

  • Deriving Tabular Event-Based Specifications

    from Goal-Oriented Requirements Models - Renaud De Landtsheer, Emmanuel Letier and Axel van Lamsweerde

  • Bahill A.T. And Dean F.F., Handbook of Systems Engineering and Management


  • Login