Research Report on Current Trends in Requirements Engineering

July 2009

Research Report on

Current Trends in

Requirements Engineering

2

Research Method

Finding Related Researchers

Finding Related Journals

Finding Related Courses

Taking Related Courses &

Reading their references

Finding Related Books

Finding Related Research Groups

Finding Related Conferences

Finding Related Projects

Finding Related Papers

Collecting required

Knowledge

3

Research Method











Collecting required

Knowledge

4

Results

Collected Knowledge Understanding Requirements Engineering Drawing Research Tree Defining Interested Research Area

5

Abbas [email protected]

Oral Comprehensive Exam Intelligent Systems Labhttp://ceit.aut.ac.ir/islab

Outline

Introduction to Requirements Engineering Research Tree Interested Research Area Research Plan

6



User

RE RE

TechniquesTools

...

system Environment

Feasible? Cost-effective?Wish Requirement

TechniquesTools

...

Need

Introduction to RE

7



Introduction to RE (Cont.)

RUP Definition: A systematic approach to • eliciting, • organizing, • documenting the requirements of the system, • establishing and maintaining agreement

between the customer and the project team on the changing requirements of the system.

8


Oral Comprehensive Exam 8Intelligent Systems Labhttp://ceit.aut.ac.ir/islab


9




Ian Sommerville Definition: Appropriate mechanism for

Understanding what the customer wants, Analyzing needs, Negotiating a reasonable solution, Validating the Specification and Managing Changes in requirements.

10




We Consider RE as: A systematic and disciplined approach to

Eliciting, Organizing, Documenting (Specifying), Analyzing, Validating and Managing changes in the requirements of the

system.

11



Why Requirement Engineering?

If we don’t engineer the requirements: In most systems, It’s highly likely that you’ll build a

very elegant software solution that solves a wrong problem.

The result is: Wasted time and money Personal frustration Unhappy Users

12


Oral Comprehensive Exam12Intelligent Systems

Labhttp://ceit.aut.ac.ir/islab

RE Process Schema

13



Requirements Engineering Process

Generic activities common to all RE processes: Requirements Elicitation; Requirements Analysis; Requirements Validation; Requirement Specification Requirements Change Management.

14



Results of Incorrect Requirements

Phase in Which Requirement is Found Cost Ratio

Requirements 1

Design 3-6

Coding 10

Development Testing 15-40

Acceptance Testing 30-70

Operation 40- 1000

15



Challenged software projects

16



Outline


17

Research Method











Collecting required

Knowledge

18



Resources (Value)

19




Resources (Value)

20



Papers (Share by Important Activities)

21




Papers (Share by Important Activities)

22




23



Tools, Research Groups, Projects (Share by Important Topics)

24





25





26



Surveys

A Quantitative Assessment of Requirements Engineering Publications--1963-2008 (2009)

Requirements Engineering: In Search of the Dependent Variables (2008)

Ten years of Australian Workshop on Requirements Engineering (2007)

Survey on the Use of Formal Languages/Models for the Specification, Verification and Enforcement of Network Access-lists (2006)

Requirements Elicitation: A Survey of Techniques, Approaches, and Tools (2005)

Role of Requirements Engineering in Software development Process (2003)

27



Surveys (Cont.)

Critical Success factors for the improvement of Requirements Engineering Process (2003)

Research in Software Engineering: an Analysis of the literature (2002)

A Survey of Practices and Problems Associated with Incomplete User Requirements Document (2001)

Requirements Engineering: A Roadmap (2000) A Survey of Software Requirements Specification

Practices in the New Zealand Software Industry (1999) A Tool Survey on Z Specification and Refinement (1999)

28



Books

Dines Bjørner, From Domains to Requirements; The Triptych Approach to Software Engineering, Draft Version, Springer, June 7, 2009.

Dines Bjørner, Software Engineering 2: Specification of Systems and Languages, 2006.

Gerard O’Regan, Mathematical Approaches to Software Quality, Springer –Verlag London Limited, 2006, ISBN -13: 978-1-84628-242-3.

Elizabeth Hull, Ken Jackson, Jeremy Dick, Requirements Engineering, Springer Verlag, Second Edition, 2005, ISBN:1-852-33577-7.

Jim Davies and Jim Woodcock, Using Z: Specification, Refinement and Proof, Prentice Hall International Series in Computer Science, 1996, ISBN 0-13-948472-8.

29



Resource Journals

Requirements Engineering Journal, Springer, ISI. Formal Aspects of Computing, Springer, ISI. IEEE Transactions on Software Engineering, ISI. ACM Computing Surveys, an ACM Journal. ACM Transactions on Software Engineering and Methodology (TOSEM). ACM SIGSOFT Software Engineering Notes IBM Journals IEEE Transactions on Software Engineering Information and Software Technology (Elsevier Inc.) International Journal of Software Engineering and Knowledge

Engineering (IJSEKE) Journal of Systems and Software (Elsevier Inc.) Software Process: Improvement and Practice

30



Resource Conferences

IEEE International Requirements Engineering Conference

IEEE International Workshop on Requirements Engineering

International Working Conference on Requirements Engineering: Foundation for Software Quality

Fundamental Approaches to Software Engineering IEEE International Conference on Software Engineering

and Formal Methods Australian Workshop on Requirements Engineering

31




RE

Elicitation

Analysis

V & V

Specification

Management

Techniques

Tools

Techniques

Tools

Techniques

Tools

Languages

Formal

Changes Management

Goal Oriented

Scenario Based

Others

Tools

Formal Tools

Tools

Modeling

Tools

Formal

ToolsTracing

Tools

32



Outline


33




Papers (Share by Main Activities)

34




Tools, Research Groups, Projects (Share by Main Topics)

35



Result

V & V Specification

Techniques

Tools

Languages

Formal

Tools

Formal Z

Tracing

Tools

Case Study

36




Outline

37



Research Plan Activities:

Completing the Requirement Specification & Verification Survey. Completing the role identification of Formalism in it. Identifying related open problems. Preparing proposal document

Outputs: Submit a paper entitled “How Z helps to specify the requirements of

engineering software” to 18th IEEE International Requirements Engineering Conference (RE10), September 27th – October 1st , 2010, Sydney, Australia.

Submit a paper entitled “Requirements Engineering: Trends and Issues” to Requirements Engineering Journal, Springer, ISSN: 0947-3602.

Formal Requirement Specification (FRS) Technical Report

http://www.re10.org/

http://www.springerlink.com/content/102830/

38



Requirements Elicitation

Elicitation / capture / discovery / acquisition The first stage in considering the problem the software

system should be able to solve. After system engineering process which defines the context

and goal of the software. The task:

establishing of boundaries and requirements for the software system. Carried out by:

interaction with stakeholders and detailed studying of corresponding knowledge domains.

A human activity.

39



Requirements Elicitation (Cont.)

The most widespread techniques are: interviews, scenarios, prototypes, facilitated meetings, observation, etc.

40



Requirements Analysis

After requirements were discovered they must be analyzed to: Necessity (need for the requirement);

Detect and resolve drawbacks in them (for example, consistency,

conflicts, ambiguity situations, completeness, etc);

Improve their quality;

They must be structured and refined;

Discover the bounds and properties of the system;

Discover how system will interact with the environment;

Another necessary analysis.

41



Requirements Analysis (Cont.)

The most widespread techniques are: Negotiation classification, conceptual modeling,

Object Oriented Modeling UML

prioritization, etc.

42



Requirements Specification

Software Requirements Specifications (SRS): a complete description of the behavior of the system to

be developed will assist the potential users

to determine if the software specified meets their needs or how the software must be modified to meet their needs

Includes a set of use cases describe all of the interactions that users will

have with the software, numerical values, limits and measurable attributes which may

be checked on the working system.

43



Requirements Specification (Cont.)

The basic issues that the SRS writer (s) shall address: Functionality. What is the software supposed to do? External interfaces. How does the software interact with people,

the system‘s hardware, other hardware, and other software? Performance. What is the speed, availability, response time,

recovery time of various software functions, etc.? Attributes. What are the portability, correctness, maintainability,

security, etc. considerations? Design constraints imposed on an implementation. Are there

any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.?

44

An SRS should be: Correct Unambiguous Complete Consistent Ranked for importance and/or stability Verifiable

there exists some finite cost-effective process with which a person or machine can check that the software product meets the requirement

Modifiable Traceable

the origin of each of its requirements is clear and It facilitates the referencing of each requirement in future

development or enhancement documentation.




45




The corresponding techniques may be divided into two separate major classes:

Natural Language (NL) based Drawback

difficult for automated processing based on special languages

universal approaches Unified Modeling Language

domain dependent Z Notation, B-Method)

drawback difficult for non-experts to understand Which limits their practical application.

46



Validation & Verification

Verifying a system: Building the system right: Ensuring that the system complies with the system requirements

and conforms to its design. Validating a system:

Building the right system: making sure that the system does what it is supposed to do in its

intended environment. determines the correctness and completeness of the end product, ensures that the system will satisfy the actual needs of the

stakeholders.

47



48



Validation & Verification (Continue)

Verifying requirements: Proving that each requirement has been satisfied. can be done by

logical argument, inspection, modeling, simulation, analysis, expert review, test or demonstration.

49




Validating requirements: Ensuring that the set of requirements is correct, complete, and

consistent, a model can be created that satisfies the requirements a real-world solution can be built and tested to prove

that it satisfies the requirements. If RE discovers that the customer has requested a

perpetual-motion machine, the project should be stopped.

50




Validation to ensure that the software engineer has correctly

understood the customer‘s requirements and needs. for conformance with company standards To ensure that the requirements are

understandable, consistent, complete.

Formal notations offer the important advantage of permitting the above properties to be proven

51



Requirements Change ManagementChange requests come from many sources throughout each iteration of the product lifecycle

Maint

Test

Code

Design

Req

Customer andEnd-User inputs

MarketingNew

Feature

NewRequirement

Bug

Help DeskEnd-User inputs

ApprovedDecisionProcess(CCB)

Single Channel for Approval

Coders inputsTesters inputs

ChangeRequest (CR)

52



Others

Including: Process, Application, Necessity, Survey, Weakness, Benefits, Roadmap Agent Oriented RE Service Oriented RE Object Oriented RE …

53



Trends and Issues

The results are based on analyzing more than 2,500 publications in the area of requirements engineering over a period of 16 years (1989-2005)

Eustace Asanghanwa, Alan M. Davis, Oscar Dieste, Ann M. Hickey, Natalia Juristo, Ana Moreno, “Requirements Engineering Research: A Microcosm of International Economic Trends”, International Working Conference on Requirements Engineering: Foundation for Software Quality (RefsQ’05), Porto, Portugal, July 2005.

54




RE publications per country

55




RE Publications per region

56




Regional growth patterns of RE publications

57



Trends and Issues (Cont.)

Davis, A., and A. Hickey, “A Quantitative Assessment of Requirements Engineering Publications--1963-2008”, International Working Conference on Requirements Engineering: Foundations for Software Quality (REFSQ’09), Amsterdam, The Netherlands, June 2009.

The results are based on analyzing more than 5,200 publications in the area of requirements engineering

Documents

Research Report on Current Trends in Requirements Engineering