1 of 83

CHAPTER 02

REQUIREMENTS ENGINEERING

FOR WEB APPLICATIONS

2 of 83

CHAPTER OUTLINES

2.1 Introduction

2.2 Fundamentals of Requirements Engineering

2.3 RE Activities- Process, Planning and Design

2.4 RE Specifics in Web Engineering

2.5 Principles of RE of Web Applications

2.6 Types of Requirements

2.7 Notations and Tools for RE

2.8 Conclusion

2

3 of 83

LEARNING OUTCOMES

By the end of this chapter, student should be able to:

Understand the fundamentals of Requirements Engineering
Describe RE activities - process, planning and design
Discuss RE specifics in web engineering
Highlight principles of RE of web applications
Differentiate types of Requirements Engineering
Describe the notations and tools for RE

3

4 of 83

2.1 INTRODUCTION

4

5 of 83

INTRODUCTION

5

This picture describes the challenges of communicating and executing customer requirements, It is written from a software developer’s, Phil Hord, point of view and can sadly be related to all other areas of the industry. Different people with elaborate things differently. It might be different from

How the customer explained it. The customer usually has no clue what he really needs. He thinks he does, but he can also think of extra features he’ll never use. He’ll demand them up front, because he’s afraid he won’t get them added later.
How the project leader understood it. The guy in charge of the project usually gets some critical detail wrong. It’s often wrong in a way that makes it useless, but it snowballs from there into comedy.
How the analyst designed it. The analyst has to decide how to fix the leader’s misunderstanding of the project. A common “fix” is to break something else to work with our existing design.
How the programmer wrote it. Programmers are notorious for not understanding the essential features of a project. They implement things quite literally, sometimes.
How the business consultant described it. Marketing folks are the engineers’ nightmares. They sell the customer on the glowing, cushy features of this project, paying no attention to the truth or practicality of the situation.
How the project was documented. Documentation is usually an afterthought, or an I-thought. As in, I thought someone else was writing it.
What operations installed. Sometimes we spend months getting certain features to work, only to find out later that those features were never installed at the customer site because A) they didn’t work, B) the installer didn’t understand how it worked, or C) someone was afraid the fixes were no good.
How the customer was billed. Yeah, software is expensive. We get to charge for all our clueless machinations.
How it was supported. “Is this feature causing the customer to call tech support? Perhaps we should remove it.” Eventually, you end up with the basic stub of the project.
What the customer really needed.

The thing is, it would be so much easier if we could ever get to this simple starting point….But we never do…

6 of 83

INTRODUCTION

What do you understand from the scenario shown in the previous slide?

6

7 of 83

LEARNING OUTCOME #01

Understand the fundamentals of Requirements Engineering.

8 of 83

2.2 FUNDAMENTALS OF � REQUIREMENTS ENGINEERING (RE)

9 of 83

RE DEFINITION AND GOAL

Definition

Goal

9

10 of 83

RE PROCESS

What are the requirement engineering processes?

10

Figure 2.1 : Requirements Engineering Process

11 of 83

RE PROBLEMS

What happen to a project if it is developed without RE?

11

12 of 83

RE PROBLEMS (CONT’D.)

List the problems due to poor RE.

12

Problems due to poor RE

As per the survey report of European Software Institute (ESI) in 1995, more than half of the companies under survey specified poor requirements engineering as a major problem.
In another survey conducted on 340 companies in Austria in 1995, more than two-thirds of these companies considered the RE as a major problem.
According to the Standish group report in 1994, when 8000 projects were studied, it was found that 30% of the projects failed before their completion date and the remaining 70% projects did not even meet the user’s needs. The reason for this was again poor RE.
Then, in another survey on Web projects conducted by the Cutter Consortium Group in 2000, it was reported that only 16% of the Web systems met the customer’s requirements and 53% of the deployed systems did not satisfy the required capabilities.

13 of 83

RE BENEFITS

Why RE is important?

13

14 of 83

THE CHALLENGES

What are the main challenges in Requirement Engineering?

14

15 of 83

THE SOLUTION

What is requirements elicitation?

15

16 of 83

REQUIREMENT DEFINITION

Define requirement as by IEEE Std. 610.12.

List TWO (2) types of requirement.

16

17 of 83

TYPES OF REQUIREMENT

What is the difference between functional and non-functional requirement?

Functional requirements

Non-functional requirements

17

18 of 83

NON-FUNCTIONAL REQUIREMENTS

Both client and developer must ________________ on the non-functional requirements to identify the minimum critical number of _____________________.
Use the ______________ of non-functional requirements to generate _____________.
List the examples of non-functional requirements.

All these requirements are summarized in SRS document, which act as ______________ between the developer and the customer.

18

19 of 83

REQUIREMENT ELICITATION POINTS

What are the main points to consider during eliciting project requirements from the customer?

19

20 of 83

LO #01 SUMMARY

By the end of this chapter, student should be able to:

Understand the fundamentals of Requirements Engineering

Concept of Requirement Engineering
Fundamentals of Requirement Engineering

20

21 of 83

LEARNING OUTCOME #02

Describe RE activities - process, planning and design

22 of 83

2.3 RE ACTIVITIES�PROCESS, PLANNING AND DESIGN

22

23 of 83

RE ACTIVITIES

RE is an umbrella activity. Define umbrella activity.

List all the activities of RE.

23

24 of 83

RE ACTIVITIY 01

24

25 of 83

REQUIREMENTS ELICITATION DESCRIPTION

RE methods aim at improving communication among the developers, clients and the users.
What are the developer's tasks?

25

26 of 83

REQUIRMENTS ELICITATION TECHNIQUES

List FIVE (5) ways in achieving the elicitation goal.

26

27 of 83

REQUIREMENTS ELICITATION TECHNIQUES (CONT’D.)

Briefly describe:

Interview

Brainstorming

Facilitated Application Specification Technique (FAST)

Quality Function Deployment (QFD)

Use case approach

27

28 of 83

REQUIREMENTS ELICITATION TECHNIQUES (CONT’D.)

Define the followings:

Scenario

Use case

Natural language

28

29 of 83

INFORMATION ELICITATION METHODS

List TWO (2) information elicitation methods

29

30 of 83

JOINT APPLICATION DESIGN (JAD)

What is the main aims of JAD?

Briefly describe JAD process.

30

31 of 83

JOINT APPLICATION DESIGN (JAD) (CONT’D.)

What is the final deliverable of JAD process?

List JAD actors.

31

32 of 83

JOINT APPLICATION DESIGN (JAD) (CONT’D.)

List and describe JAD activities.

32

33 of 83

MAINTAINING TRACEABILITY

Discuss traceability.

33

34 of 83

MAINTAINING TRACEABILITY (CONT’D.)

Discuss the approaches used in maintaining traceability.

34

35 of 83

RE ACTIVITY 02

35

36 of 83

DOCUMENTING THE RE

Describe requirements analysis document (RAD).

Who are the audience for the RAD?

36

37 of 83

DOCUMENTING THE RE (CONT’D.)

Discuss the requirement engineering documentation process.

37

38 of 83

RE ACTIVITY 03

38

39 of 83

VERIFICATION AND VALIDATION

Differentiate verification and validation.

Verification

Validation

How does requirements validation happen in traditional projects and in Web engineering field?

39

40 of 83

RE ACTIVITY 04

40

41 of 83

REQUIREMENTS MANAGEMENT

Describe the two main activities of requirement management.

41

42 of 83

LO #02 SUMMARY

By the end of this chapter, student should be able to:

Describe RE activities - process, planning and design

Describe requirement elicitation methods.
Describe requirement documentation process.
Differentiate requirement validation and verification.
Describe requirement management activities.

42

43 of 83

LEARNING OUTCOME #03

Discuss RE specifics in web engineering.

44 of 83

2.4 RE SPECIFICS IN WEB ENGINEERING

44

45 of 83

RE IN TRADITIONAL SE & WEB E

List the differences between RE in traditional software engineering and in web engineering.

45

1. Multidisciplinarity: As Web site and Web application engineering focus on the best GUI, therefore the people of different areas like multimedia experts, content authors, software architects, usability experts, database specialists or domain experts are required. Also, the non-homogeneous stakeholders, with the multidisciplinarity of stakeholders, make RE more difficult. This is so because the people involved in Web projects have different nature, views and languages that need to be reconciled.

2. Non-availability of stakeholders: In normal software engineering projects, during RE, stakeholders are more or less clear, but in Web engineering projects, during RE, the stakeholders are not clear. It is the job of the project manager to find out the potential stakeholders involved in Web projects and to ensure whether they can provide real type of requirements. For example, it is easy to list the stakeholders theoretically, but practically, it is difficult to get them.

3. Volatility of requirements: Requirements and constraints of any Web project keep on changing, just as it happens for normal projects. Requirements keep on changing due to the continuous change in the users’ requests. Web applications and their environments are highly dynamic. The Web requirements are highly unstable. This is so because every day newer technologies and newer apps are being developed.

4. Dynamic operational environment: The operational environment of a Web site or a Web application is very much dynamic and difficult to predict. It is difficult for a Web developer to find out the factors that decide what a Web user desires in his project. For example, changing bandwidths will affect the response time of mobile applications, but it may be out of the view of the development team.

5. Affect of old systems: Legacy systems are the old existing systems. A Web application project is worked upon by integrating the existing software components like COTS or open source software. Web developers are often confronted with a challenge to integrate these old systems. This may be due to the cost factor (as imposed by the management). It is to be noted that the components that need to be integrated very strongly influence the requirements and the architectural style of the future system. In such scenarios, waterfall model is not suitable. This means that during the RE, the Web developers must be aware of the system architecture and the architectural restrictions (constraints). An iterative approach, as proposed in twin-peaks model, is much more apt here.

6. Importance of quality factors: Quality factors for Web applications should be considered also. Web quality is not a simple and atomic term. In fact, it is a multi-dimensional and abstract concept. Three quality problems are very significant— incompleteness, inconsistency and semantic ambiguities. These three factors affect every field of domain of engineering. But, Web applications involve many other quality factors like representational conciseness, interoperability and interpretability of the data. The factors like logical or formal consistency, trustworthiness and relevancy constitute another set of dimensions that determines the quality of the Web of data. The challenge is to measure the quality factors. Bizer (2007) listed some quality factors like accuracy, timeliness, completeness, relevancy, conciseness and consistency. Flemming (2010) suggested uniformity of Web, Web versatility, and Web comprehensibility, amount of Web data, Web validity, Web licensing, Web accessibility and Web performance. The quality factors related to Web apps that are still not explored much are interlinking, believability and licensing. Web application developers must be aware of I Know It When I See It (IKIWISI) phenomenon. It means that users will not be able to understand a Web application by just looking at the abstract models, but rather they need to experiment with it. Prototypes of some important scenarios may be built.

7. Quality of content: Several RE methods for Web projects do exist. But they do not stress much on the quality of content. Both the creation of the content and its maintenance are equally important. During the RE, it is mandatory to define the quality of the content. Some quality features include accuracy, objectivity, credibility, relevance, actuality, completeness or clarity of contents. Today many content management systems (CMSs) are also very popular that allow us to represent the Web content more precisely and consistently by separating out the content from its layout and offering content editing tools.

8. Lesser developer experience: The existing Web technologies, tools, standards, languages, etc. are still in their infancy. So, this can result in wrong estimates when doing cost and time estimations for them.

9. Rigid delivery dates: The Web projects are very much tuned to be delivered on time. They have fixed project deadline. And under such conditions, prioritization of requirements is not an easy task. There is no agreed standard for size measurement for a Web project like we have LOC or FP methods for traditional projects.

10. Vulnerability issues: It has been found that Web applications are much more vulnerable to hacks as compared to any traditional application. This is so because Web projects are very complex and are to be available (24 × 7 × 365) days. This may be one of the reasons of easier data leakages from Web sites.

46 of 83

RE IN TRADITIONAL SE & WEB E (CONT’D.)

Describe the followings:

Multidisciplinary

Non-availability of stakeholders

46