Professional Computing (CITS3200) Requirements Analysisteaching.csse.uwa.edu.au/units/CITS3200/lectures/Bulandran_08.pdf · Professional Computing (CITS3200) Requirements Analysis

1

Bulandran, S.-1-13th Aug 2008

Professional Computing (CITS3200)

Requirements Analysis

Sujatha BulandranThe University of Western Australia

Professional Computing

CITS3200



Overview

1.0 Requirements Analysis / Requirements Engineering (RE) - Definition? - Why it is important?

2.0 Requirements Engineering Models

3.0 Activities in Requirements Engineering

4.0 Requirements Evolution

5.0 The desirable Skills for Requirements Engineering

6.0 Requirements Engineering Problems

References

2



1.0 Introduction

In the early stage of software development,

capturing, structuring and representing user requirements

stakeholders speaks different languages – Business andTechnical groups

possibilities for miscommunication

the process of gathering and defining user’s needs



1.0 Requirements Engineering (RE)?

”Requirements engineering is an activity that involves capturing, structuringand accurately representing the client’s requirements in a manner that can beeffectively implemented in a system that will conform to the client’sspecifications”

Sawyer, P. and Kotonya [1]

“Requirement Engineering covers all of the activities involved in discovering,documenting and maintaining a set of requirements for a computer-basedsystem”

I.Sommerville [2]

“Requirement Engineering aims at defining the requirements of the systemunder construction which includes two main activities which are requirementelicitation and analysis”

Bernd Bruegge and Allen H. Dutoit [3]

3



1.0 Why Requirements Engineering(RE) is important?

In software development projects, the RequirementsEngineering Process (REP) can influence thedevelopment:

cost

time

effort

quality



1.0 Major cause of errors in Softwaredevelopment

Leffingwell and Widrig [4] had stated that one-third of the totaldefects delivered in software projects are derived from requirementserrors by referring to several case studies.

Requirements processes considered as the source of most (50% ormore) critical quality problems in software development [5].

The top five causes of poor software cost estimation are related toissues with requirements, mainly involving frequent requirementschanges, missing requirements, insufficient user communication,poor specifications, and insufficient analysis of requirements [6].

Embedded real-time software also has the similar error patterns asother types of software. The major source of errors found (36%) arerelated to requirement issues [7].

4



1.0 Correcting Requirements Defects

The cost for correcting requirements defects in later part of the development phase is more expensive compared to

Requirements Engineering

Figure 1: Relative cost to correct a requirement defect depending on when it is discovered [8]



Overview







References

5



2.0 Requirements Engineering ModelsIn the Context of RE Process (REP)

Requirements engineering

System des ign

System acquis ition

Figure 2: Context of Requirements Engineering Process [2]



Waterfall Model

RequirementsElicitation

Requirements Analysisand Negotiation

Requirements Specificationand Validation

Requirements Managementand Documentations

Figure 3: The Waterfall Model for Requirements Engineering Process [3]

6



Iterative Model

Figure 4: The Iterative Model for Requirements Engineering Process [2]



Spiral Model

Requirements elici tation Requirements analys is andnegotiation

Requirements documentationRequirements validation

Informal statement ofrequirements

Agreedrequirements

Draft requirementsdocument

Requirementsdocument and

validati onreport

Decision point:Accept documentor re-enter spiral

START

The REP iterates in a spiral until the decision point

Figure 5: The Spiral Model for Requirements Engineering Process [2]

7



Agile Requirements Engineering

Figure 6: The Agile Approach for Requirements Engineering Process [9]



Overview







References

8



Requirements Elicitation invokes the task to find out the requirements

Requirements Analysis and Negotiation represents the problem domain which will be built

Requirements Specification and Validation define the right system essence of agreement between the users and developers

Requirements Management and Documentation ensure the software continues to meet the expectations of the users

3.0 RE Activities



Overview







References

9




Figure 7: Requirements Evolution [10]



Managing Requirements Changes

Requirements Elicitation

RequirementsAnalysis andNegotiation

Requirements Specificationand Validation

RequirementsManagement andDocumentations

Informal statements ofrequirements

Agreedrequirements

Requirementsdocuments andValidationReports

Draft requirementsdocuments

Draft requirementsdocuments

Draftrequirementsdocuments

Repository

Figure 8: Requirement Engineering Process Centered at RMD

10



Overview







References



• mathematician (eg argument by elimination)

• historian (eg use of analogies)

• epistemologist (eg insight into what knowledge required by task)

• psychologist (eg appreciation of cognitive load)

• manager (eg selecting appropriate skills)

• learner (eg appropriateness of knowledge)

5.0 Required Skills for RE [12]

11



• scholar (eg underlying governing principles)

• bookkeeper (eg organizing memory)

• researcher

• negotiator

• tester

5.0 Required Skills for RE [12]



Overview







References

12



• Customers don't (really) know what they want

• Requirements change during the course of the project

• Danger of false assumptions during requirements gathering activities

• Customers have unreasonable timelines

• Communication gaps exist between customers, engineers and project managers




• the development team doesn't understand the politics of the customer's organization.

• are found in organizational contexts, with associated conflicts,expectations and demands of the proposed system

• are dynamic –they change while being solved

• solutions require interdisciplinary knowledge and skills

• the knowledge base of the analyst is constantly evolving

6.0 Requirements Engineering Problems (cnt.)

13



Conclusions

Reduces development cost

POSSIBLE OUTCOMESFROM EFFECTIVEREQUIREMENTSENGINEERINGPROCESS

Increases the quality ofsoftware development process

Reducesdevelopmenttime

Reduces the rate ofdefects in requirementsdocuments



REFERENCES

[1]Sawyer, P. and Kotonya, G. SWEBOK: Software Requirements EngineeringKnowledge Area Description.http://www.swebok.org

[2] Sommerville I (2001): Sotfware Engineering, 6th ed, Addison-Wesley Publishing CompanyInc.

[3] Bruegge B., Dutoit A.H (2000): Object-Oriented Software Engineering Conquering Complexand Changing Systems, Prentice Hall.

[4] Leffingwell, D and Widrig, D (1999) Managing Software Requirements: A Unified Approach,Addison-Wesley, pp5-13.

[5] Weinberg, G M (1971) The Psychology of Computer Programming, Van Nostrand Reinhold.

[6] Davis, A M (1995) 201 Principles of Software Development, McGraw-Hill.

[7] Vinter, O, Poulsen, P M, Thomsen, J M, Nissen, K (1996) “The Prevention of Errors throughExperience-Driven Test Efforts”, Tech. Project D-259, Delta, Horsholm, Denmark.

14



REFERENCES (cont.)

[8] Grady, R B, “An Economic Release Decision Model: Insights into Software ProjectManagement.” In Proceedings of the Applications of Software Measurement Conference, 227–239. Orange Park, FL: Software Quality Engineering, 1999.

[9] Scott W. Ambler, 2001-2006. Agile Modeling: Effective Practices for Extreme Programmingand the Unified Processhttp://www.ambysoft.com/books/agileModelling.html

[10] Bach, J (1999) Reframing Requirements Analysis, IEEE Computer Society, pp 120 – 122

[11] Armin Eberlein and Julio Cesar Sampaio do Prado Leite, ‘Agile Requirements Definition: AView from Requirements Engineering’http://citeseer.ist.psu.edu/cache/papers/cs/26480

[12] Armarego, J, “Educating Res effective learning for professional practice”, Symposium onSoftware Requirements Engineering 2008.



REFERENCES (cont.)

[13] Ogren, Ingmar, “Requirements Management as a Matter of Communication”, CROSSTALK,April 2000http:/www.stsc.hill.af.mil/crosstalk/2000/04/ogren.html

[14] Lawrence Pfleeger S (2006): Software Engineering, Theory andPractice, 3rd Edition, Prentice Hall.

[15] Pressman P, S (2001): Software Engineering, A Practioner's Approach,Fifth Edition, McGraw-Hill.

15



Thank you for your Attention!

Any Questions?

Documents

Professional Computing (CITS3200) Requirements Analysisteaching.csse.uwa.edu.au/units/CITS3200/lectures/Bulandran_08.pdf · Professional Computing (CITS3200) Requirements Analysis