LECTURE VIDEOS

00:00:00:11 - 00:00:42:07

Unknown

Welcome to the course. Chapter two Requirements Engineering for Web Applications. The following content is provided under a Creative Commons License. Chapter Outlines. This is how we're going to cover this topic. First, we begin with the introduction. Dan followed by the fundamentals of requirements engineering. After that, we're going to discuss on the requirement engineering activities, requirement engineering specifics in web engineering, and then the principles of requirement engineering of web applications followed by the types of requirements and the notations and also tools for requirement engineering.

00:00:42:07 - 00:01:22:26

Unknown

And finally, we will close that the chapter with the conclusion. Topic Learning Outcomes. By the end of this chapter, students should be able to understand the fundamentals of requirements engineering, describe requirement engineering activities - the process, planning and design, discuss requirement engineering specifics in engineering, highlight principles of requirement engineering of web applications. Differentiate types of requirements engineering and describe the annotations and tools for requirement engineering. Introduction.

00:01:22:26 - 00:01:55:20

Unknown

Introduction. This picture describes the challenges of communicating and executing customer requirements. It is written from a software developer's point of view and can certainly be related to all other areas of the industry. Different people will elaborate things differently. It might be different from how the customer explained it and then how the project leader understood it, how the analyst designed it, how the programmer wrote it.

00:01:56:11 - 00:02:28:09

Unknown

How the business consultant describe it, how the project was documented, and then what operations installed, how the customer was billed, how it was supported, but then 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 it. Learning Outcome Number One.

00:02:28:16 - 00:03:09:25

Unknown

Understand the fundamentals of requirements engineering. Fundamentals of requirements engineering. Requirement, Engineering Definition and Goal. What is the requirements engineering? The process of analyzing, documenting and validating the requirements of the software is known as requirements engineering or the R E. The basic goal of the requirements phase in the software development lifecycle, the SDLC is to produce a software requirement specification document or the SRS document as an output or a deliverable.

00:03:09:25 - 00:03:52:22

Unknown

The process of developing this document is called requirements engineering. According to Davis, requirements engineering is the organized use of principles, techniques, tools and languages for the cost effective analysis, documentation and changing user needs. Requirement Engineering Process. The requirement engineering process involve all of the following activities. You may refer to the figure. There are basically two main activities, the requirements definition and the requirements management. For requirements definition, there are four sub-activities in acquiring the requirements.

00:03:53:13 - 00:04:40:06

Unknown

The activities are the requirements elicitation, requirements modeling, requirements documentation and requirements review. The requirements management activities are to manage the requirements acquired in the earlier process. The two sub-activities of requirements management are requirements data management and also requirements traceability. All these activities will be further discussed in the next sections of the chapter. All the activities in the requirement engineering processes are very essential for a successful completion of any web project. So, the requirements must be complete, unambiguous and consistent.

00:04:40:06 - 00:05:19:28

Unknown

Otherwise, it will lead to the termination of projects. Even web application requirements also suffer from volatility problems. But for web projects, technical feasibility, managerial feasibility, and also economic feasibility play an important role. This projects are well developed using parallel processes, and they are very costly. But without requirements engineering, again, you possibly land on developing a project that has poor user acceptance, unsuccessful plans and also complex architecture.

00:05:21:15 - 00:05:54:23

Unknown

The followings are some of the major bottlenecks faced in the previous years due to poor requirement engineering. As per the survey report of European Software Institute in 1995, more than half of the companies under survey specified poor requirements engineering as a major problem. Another survey conducted on 340 companies in Austria in 1995, more than two thirds of these companies considered that RE a major problem.

00:05:55:27 - 00:06:39:20

Unknown

And according to the Standish Group report, in 1984, when 8000 projects was studied, it was found that 30% of the projects failed before the completion date, and the remaining 70% of the project did not meet the users need. The reason for this was again poor R E. Then in another survey on web projects conducted by the Cutter Consortium Group in 2000, it was reported that only 16% of the Web system met the customers requirements, and then another 53% of the deployed systems did not satisfy the required capabilities.

00:06:41:03 - 00:07:13:00

Unknown

In a nutshell, requirement engineering is very important if you have to avoid the time slippages and cost overruns. Another problem with the web projects is that lack of experiences people. Therefore, there is a need to use web engineering to solve these problem. The challenges. The web stakeholders include the content authors, domain expert, usability experts or even marketing professionals.

00:07:13:26 - 00:07:47:07

Unknown

The satisfaction of these stakeholders is the focal points of any project manager, and perhaps it is the biggest challenge. The problems of understanding the problem domain of any web application still persist. It is very difficult to reconcile the objective of the stakeholders as they have conflicts based on their expectations, backgrounds and agenda. Some of these conflicts may be between the desired set of capabilities and the available budget,

00:07:47:25 - 00:08:28:08

Unknown

the project schedules, the design quality or even the desired technology, and the developers skills and experiences. The solution. A project manager must understand that the identification of such risks must be carried out earlier during the web development cycle. If it is not done, then the defects will get amplified during the later SDLC phases. The process of acquiring knowledge about the specific problems domain through various techniques to build the requirements model is called requirements elicitation.

00:08:28:08 - 00:09:09:20

Unknown

What is a requirement? IEEE Standard Six One Zero One Two defines a requirement as an ability needed by a user to solve a problem or achieve an objective. It is also defined as a condition that must be met to satisfy a contract, and standard. Requirement also can be referred to as a documented representation of a capability or condition. Requirements are basically of the following two types; the functional requirements and the nonfunctional requirements. Types of requirements.

00:09:10:12 - 00:09:50:21

Unknown

As mentioned earlier, there are two types of requirement functional requirements and non functional requirements. Functional requirements define systems capabilities and services. For example, the functionality, the maintainability, traceability, consistency, unambiguity and etc. of the system, while the nonfunctional requirements are used to define the desired levels of quality. These levels of quality may range from the user interface, look and feel to response time requirements to the security issues.

00:09:51:24 - 00:10:35:25

Unknown

Nonfunctional requirements. To elicit nonfunctional requirements, both client and developer must collaborate so that they can identify some minimum numbers of system attributes that are critical for the user. There may be some conflicting requirements also. To solve such conflicts, the client and the developer prioritize nonfunctional requirements. Practically, analyst use taxonomy of nonfunctional requirements to generate a checklist of questions to help the client and developers focus on the nonfunctional aspect of the system.

00:10:35:25 - 00:11:25:05

Unknown

Once they have identified a set of nonfunctional requirements, they can organize them into refinement and dependency graph to identify further nonfunctional requirements and conflicts, if any. Nonfunctional requirements deal with the issues like quality attributes, constraints, goals and the non behavior requirements. Other categories of nonfunctional requirements are such as usability of web, reliability of web, performance of web, portability of web, maintainability of web, operation of web, and also the packaging of web. All these requirements that have been gathered are summarized in the software requirement specification,

00:11:25:15 - 00:11:53:20

Unknown

SRS document. The SRS document will act as a contract between the developer and the customer. Where do requirements originate from? Basically, customers themselves do not have a clear idea of what they actually need. They have limited technical knowledge. The followings are the points that you need to keep in mind when you want to elicit requirements from your customer.

00:11:54:10 - 00:12:24:18

Unknown

The first one is to identify the stakeholders. Who are the stakeholders? A stakeholder is anyone who has direct interests in or benefit from the system that is to be developed. The stakeholders may be business operations manager, product managers, marketing people and the end users, the software consultants, the product engineer, the software engineer to support and maintenance engineers and etc.. All these people have different views of the system

00:12:24:18 - 00:12:50:29

Unknown

that is to be developed. Then you have to recognize multiple viewpoints. All of the stakeholders mentioned earlier have different views regarding the system to be developed. Like marketing people are interested in functions and features having potential market, business people are interested in functions that can be set within minimum budget, while end users are interested in functions that will be easy to understand and use,

00:12:51:16 - 00:13:27:29

Unknown

software engineers are interested in functions and features that support existing infrastructure and support engineers may focus on the maintainability of the software. Different levels of stakeholder will have different viewpoints of the system to be developed. The third viewpoint is working towards collaboration. Customers must collaborate with themselves and software engineering practitioners to get a successful system. The task of a requirement engineer is to find common areas of requirements that all

00:13:28:21 - 00:14:02:01

Unknown

stakeholders agree and the conflicting areas of different types of stakeholders. Then, the management people can take the decision to forward or to reject these requirements. Finally, Asking the questions. Then only you can start to ask questions. The requirement engineering is a communication intensive activity because requirements gathering is an initial step for design. Three types of questions may be asked—the context free questions, questions to gather initial understanding of the problem domain and questions that focus on the effectiveness of the communication activity.

00:14:03:01 - 00:14:33:16

Unknown

That's the end of Learning Outcome Number One – The Summary. By the end of the section, students should be able to understand the fundamentals of requirements engineering, which include the concept of requirement engineering, and also the fundamentals of requirement engineering. Learning Outcome Number Two. Describe requirement engineering activities - the process, planning and design. Requirement Engineering Activities - the Process, Planning and design.

00:14:34:20 - 00:15:07:22

Unknown

Requirement Engineering Activities. The Requirement Engineering is an umbrella activity. What is an umbrella activity? Umbrella activities are a set of steps or procedure that the web engineering team follows to maintain the progress, quality, change, and list of the overall development tasks. These activities include elicitation, documentation, verification and validation and also requirements management throughout the software development lifecycle or the SDLC.

00:15:08:14 - 00:15:50:25

Unknown

The first umbrella activity of requirement engineering is requirement elicitation.

 Requirement elicitation description. The requirement engineering method aimed at improving communication among the developers, clients and the users. Developers construct a model of the application domain by observing users in their environment. They select a representation that is understandable by the clients and the users, like the scenario based use cases. They validate the application domain model by constructing a simple model of the user interface and collecting feedback from the web users. Requirements

00:15:50:25 - 00:16:26:08

Unknown

elicitation technique. Requirements elicitation can be done through elicitation process regarding a system. This can be achieved in five ways, by Question and answer, Brainstorming Facilitated Application Specification Techniques or FAST, Quality function deployment QFD and also the Use case approach. The question and answer or the interview session for requirements elicitation is used to understand the customers expectations from the software. 

00:16:26:08 - 00:16:52:05

Unknown

Brainstorming is used to emphasize on an issue or problem and then offering a lot of fundamental way out of it. Facilitated application specification technique or FAST, is used to bridge the expectation gap. This is where the difference between what the developers think they are supposed to build and what customers think they are going to get. Quality function deployment

00:16:52:05 - 00:17:20:22

Unknown

or QFD, emphasizes on the requirements which are valuable to the customer. Use case approach is a combination of text and pictures to provide a better understanding of the requirements. A scenario describes an example of the system in use. It shows interactions between a user and a system. A use case is an abstraction that describes the scenario of the system.

00:17:21:08 - 00:17:54:03

Unknown

Both scenarios and use cases are written in natural language that the web users can also understand. Information elicitation method. Elicitation of information about the project may be done by the following two methods. The first one is Joint Application Design or JAD, and the second method is by maintaining the traceability. Joint application design - JAD. The first method is joint application design or JAD.

00:17:54:20 - 00:18:31:00

Unknown

JAD aims at building consensus among the developers, the users and the clients by jointly developing the SRS document. It is a requirement gathering technique developed at IBM in 1970s. JAD suggests elicitation of requirements is done in one single workshop session in which all stakeholders participate. The users, the clients, developers and a leader sit together in one room to present their viewpoints, negotiate and come to a mutually acceptable solution.

00:18:32:19 - 00:19:07:19

Unknown

The final deliverable is a JAD document including definitions of data elements, workflows and interface screens. The final JAD document acts as an agreement among developers, users, clients, and thus, minimize requirement changes later in the development process. The main actors involved in the JAD are the customer, Sponsor or the top management person, Facilitator or project leader, Scribe or record keeper, and System analyst. In the

00:19:07:20 - 00:19:38:05

Unknown

JAD, weekly meetings are held for 2 to 4 hours. The JAD is useful for larger projects. It involves the following main activities, Project Definition. Project definition includes fact finding and information gathering. Forming a JAD team. A JAD team is formed by a facilitator and the sponsor. Kickoff Meeting. Kickoff meeting is the initial meeting that is started by the sponsor.

00:19:38:23 - 00:20:15:18

Unknown

It focuses on ensuring that all team members understand what JAD is. Regular JAD sessions, regular jet sessions are based on users availability. JAD sessions are held for discussion on planning, analysis, design and development. Traceability focuses on recording, structuring, linking, grouping and maintaining dependencies among requirements, and between requirements and other work products. The second method of requirement elicitation is maintaining traceability.

00:20:16:08 - 00:20:47:05

Unknown

Traceability is the ease with which you can traverse between different phases. It includes tracing where the requirements came from and the project they affect. Traceability enables the developers to show that the system is fully developed and the testers to show that the system satisfies their requirements. The approach used cross-references among the documents, models and the codes. Each individual element like requirement, component, class, operation,

00:20:47:10 - 00:21:25:28

Unknown

test case, etc. is identified by a unique number. Then, dependencies are documented manually. For large project, specialized database tools enable partial automation of capture, editing and linking of traceability dependencies at a more detailed level. For example, DOORS by Telelogic and RequisitePro by Rational are such tools that reduce the cost of maintaining traceability. The second umbrella activity is Documentation. Documenting the requirement engineering. tThe result of the requirements

00:21:25:28 - 00:22:05:27

Unknown

elicitation analysis activities are documented in the requirement analysis document or the RAD. These documents serve as a contract between the client and the developer, as you describe the system in terms of functional and nonfunctional requirements. The audience for the RAD includes the clients, project management, users, system analyst and also the system designers. The first part of the document includes use cases and nonfunctional requirements, whereas the formalization of the specification in terms of object models is written during analysis.

00:22:06:14 - 00:22:36:02

Unknown

This RAD should be written after the use case model is stable, that is, when the number of modifications to the requirements is optimal. Suitable degree of preciseness and formality is decided depending on the types of identified risks and the skills and experience of the expected readers. As far as the Web engineering is concerned, informal descriptions like user stories and semi-formal descriptions like use cases are quite useful.

00:22:37:00 - 00:23:14:10

Unknown

The third umbrella activity is requirements verification and validation. We know that verification is a static process of testing the documents. The requirements analysis document (RAD) is also verified. Also, we know that validation is a dynamic process of running executables (code). Similarly, requirements need to be validated. Traditional projects used reviews, inspections, prototyping, etc. for validation of requirements,

00:23:14:21 - 00:24:03:01

Unknown

but in Web engineering field, direct user participation is a must, for example, through online collection of user feedback. The last umbrella activity is requirements management. 

 Requirement management. There are two sub-activities of requirement management, which are the requirement change management and the second one is requirement traceability. As we know, requirements are not stable or fixed. They do change frequently as the user demands increases, and that regular change in the requirements and constraints on Web projects is one of the major features of the Web projects. For achieving the task of combining the new requirements and changes to the existing requirements,

00:24:03:10 - 00:24:48:23

Unknown

several methods and tools may be used. These tools help in achieving traceability, i.e., in evaluating the effect of changes by managing interdependencies among the requirements and other development artifacts (deliverables) of complex projects. Learning Outcome Number Two Summary. So, by the end of two chapters, students should be able to describe requirement engineering activities which include the process, planning and design. Student also should be able to describe requirement elicitation methods, describe the requirement documentation process and then differentiate requirement validation and verification, and finally describe requirement management activities.

00:24:50:02 - 00:25:45:15

Unknown

Learning Outcome Number Three. Discuss requirement engineering specifics in web engineering. Requirement Engineering Specifics in Web Engineering. A question arises as to whether there is any difference between RE in traditional or conventional software engineering and in Web engineering. The answer is yes. There are some differences and similarities too. There are ten elements to be considered which include multi-disciplinary, non-availability of stakeholders, volatility of requirements, dynamic operational environment, affect of old systems, importance of quality factors, quality of content, lesser developer experience, rigid delivery dates, vulnerability issues.

00:25:46:10 - 00:26:20:12

Unknown

Now let us see the differences between the two. Multidisciplinary. As Web site and Web application engineering focus on the best graphical user interface, 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.

00:26:21:01 - 00:26:59:01

Unknown

This is so because the people involved in Web projects have different nature, views and languages that need to be reconciled. 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.

00:26:59:15 - 00:27:30:15

Unknown

For example, it is easy to list the stakeholders theoretically, but practically, it is difficult to get them. 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.

00:27:31:03 - 00:28:05:11

Unknown

This is so because every day newer technologies and newer apps are being developed. 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.

00:28:07:04 - 00:28:35:17

Unknown

Affect of old systems: Legacy systems are the old existing systems. A Web application project is worked upon by integrating the existing software components Web developers are often confronted with a challenge to integrate these old systems. This may be due to the cost factor. 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.

00:28:36:11 - 00:29:08:16

Unknown

This means that during the RE, the Web developers must be aware of the system architecture and the architectural restrictions. 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.

00:29:09:11 - 00:29:42:29

Unknown

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. Web application developers must be aware of

00:29:42:29 - 00:30:15:03

Unknown

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. Quality of content: Several RE methods for Web projects do exist. But they do not stress much on the quality of content.

00:30:15:20 - 00:30:44:15

Unknown

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

00:30:44:27 - 00:31:15:20

Unknown

by separating out the content from its layout and offering content editing tools. 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. Rigid delivery dates. The Web projects are very much tuned to be delivered on time. They have fixed project deadline.

00:31:15:29 - 00:31:46:19

Unknown

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 for traditional projects. 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 hours a day , 7 days a week, and 365 days a year.

00:31:47:04 - 00:32:22:25

Unknown

This may be one of the reasons of easier data leakages from Web sites. So, this is the summary of Learning Outcome Number Three . By the end of the chapter, students should be able to discuss requirement engineering specifics in web engineering. Learning Outcome Number Four. Highlight Principles of Requirement Engineering of Web Applications. Principles of Requirement Engineering in Web Applications. Principles of Requirement Engineering in Web Applications.

00:32:23:08 - 00:32:59:05

Unknown

Web site and Web application projects must deal with the risks and constraints like volatility of requirements, developers with lesser experience and the effect of older solutions. The following are the five principles of the RE. Analyse The Present Business Scenarios, Stakeholders’ Feedback And Involvement, Iterative Approach of Requirements Definition, System Architecture, Risk Identifications. Principle number one - Analyze the present business scenarios.

00:32:59:18 - 00:33:24:11

Unknown

Web sites and Web applications are still in their infancy stage. They are developed without a deep understanding of the system. A Web application is not a silver bullet. It must support the customer’s business objectives too. Web engineers must understand the reasons behind the development of a new Web application. Web developers must understand how the system is embedded in its environment.

00:33:25:09 - 00:33:53:00

Unknown

According to Boehm, business analysis is useful to find out the value of a Web application with respect to the resources it uses. This understanding of system has several advantages, which are as follows. Number one, Identifying the success-critical stakeholders; Number two. Understanding the purpose of such a Web application; and Number three. Finding out the constraints on the project, if any.

00:33:53:27 - 00:34:28:17

Unknown

Principle Number Two. Stakeholders Feedback and Involvement. Stakeholders that directly or indirectly affect the success of a project must be involved, as they are very critical for a project’s success in every project phase. One should understand that the requirements of stakeholders have to be located and negotiated again and again to cope with the dynamically changing needs of the projects. Also, note that the multidisciplinarity and unavailability of stakeholders requirements are necessary for any Web application.

00:34:29:04 - 00:35:04:04

Unknown

The following requirements are necessary for any Web application. Finding and identifying the stakeholders that affect project’ssuccess; Finding the user’s requirements, bjectives and goals; Coping with different expectations, experiences and knowledge. The tools used for requirements engineering must be consistent with these requirements, should do good information exchanges, reveal hidden knowledge among stakeholders, support team learning process, share vision development among stakeholders and remove conflicting requirements,

00:35:04:04 - 00:35:40:14

Unknown

if any. Principle Number Three . Iterative Approach of Requirements Definition. Web application projects are of dynamic nature. As a project progresses, the development results can be slowly refined in more concrete terms, while continuously ensuring their consistency. Requirements are volatile, that is, they may change any time. Thus, iterative approach is better. If the development time is limited, then iterative approach will list and implement the higher priority requirements.

00:35:40:14 - 00:36:09:17

Unknown

first. Principle Number Four. System Architecture. We know that Web architecture is usually very complex due to large number of Web pages that are intermingling with each other. A complex Web architecture makes the Web site code also complex. This makes the testing difficult. The problem space is defined by the solution space; so, it is necessary to understand the technical solutions with their limitations.

00:36:10:02 - 00:36:43:20

Unknown

Thus, proper Web architecture must be designed. For this, expert Web designers are needed and this very big issue in Web engineering field. Actually, the existing technologies and old solutions have a high impact on the requirements of Web engineering. The twin-peaks model suggests the concurrent refinements of both requirements and the system architecture in an iterative fashion, with each level introducing a newer detail.

00:36:43:20 - 00:37:15:29

Unknown

Number Five. Risks Identifications. Any unwanted act that results in some loss of the project in terms of its cost, time or resources constitutes risk. A good project manager must identify the risks as the project starts. It is so because the late identification of a risk can lead to project failure, and hence, loss of several million dollars. Risks also arise due to undetected problems, unsolved issues and conflicts among the requirements.

00:37:16:20 - 00:37:37:08

Unknown

As far as the Web applications are concerned, several risks have been identified like integration of the existing components into the Web application, determination of system quality aspects or less-experienced developers. Risk mitigation is one of the important activities. The earlier it is done, the better it is!

00:37:39:09 - 00:38:07:23

Unknown

Learning Outcome Number Four. The Summary. By the end of the chapter, students should be able to highlight principles of requirement engineering of web applications. By now, students should be able to identify the five principles of requirement in engineering offer applications which include understand the present business scenarios, understand the requirements of stakeholder, understand attractive approach of web applications, defined a system structure and identify the risks.

00:38:08:27 - 00:38:45:23

Unknown

Learning Outcome Number Five. Differentiate types of requirements engineering. Types of requirements. Web engineering project requirements. Basically, the requirements are put under the following two categories: Functional requirements; and Non-functional requirements. But, for Web engineering projects, the requirements may be any of the following types: Web Functional Requirements, Content Requirements, Quality Requirements or the Non-functional Requirements, Environment of System-based Requirements

00:38:46:02 - 00:39:22:19

Unknown

Graphical User Interface-related Requirements, Evolution Requirements, and Constraints on the Project. Web functional requirements: Functional requirements refer to those requirements that specify the functionality of a given project. They are shown using use case diagrams. Contents requirements: These requirements specify the contents a Web application should show. Quality requirements / Non-functional requirements . Quality is an abstract relationship between properties of objects and information needs.

00:39:23:04 - 00:39:56:29

Unknown

It has the following four dimensions: Specification quality, Design quality, Development/ or software construction quality, Conformance quality. Specification quality: It refers to how well the specifications are specified for the product or service being provided. If all specifications of a web project are met then the other activities can follow this specification step. So, if specifications are weak, design will be weak,

00:39:57:07 - 00:40:22:17

Unknown

which results in software resting on a shaky condition, i.e., it may fail any time. Once the requirements are complete, design is completed, and then only, coding should be started. Design quality: It refers to how well the product or service to be delivered is designed. If the design is weak, then the software may fail at any time.

00:40:23:02 - 00:40:53:21

Unknown

Design involves conceptual design and engineering design. Conceptual design provides a solution from the myriad approaches available. Whereas, engineering design uses the approach selected. It reuses the details to realize the solution. Note that conceptual design is the creative part of the process, and engineering is the details part. However, in terms of software, conceptual design refers to the software architecture,

00:40:54:02 - 00:41:29:05

Unknown

navigation, number of layers, approaches to flexibility, portability, maintainability, etc. whereas engineering design refers to database design, program specifications, form design, report design, etc. Development or software construction quality: Software testing takes more time than testing in the traditional sense. Web site testing is not exhaustive. Good-quality code is obtained by following the coding guidelines of the programming languages being used.

00:41:29:19 - 00:42:01:08

Unknown

The aim is to write a reliable and defect-free code. Conformance quality: It determines how well the quality control is carried out in the organization. To measure the efficiency of quality assurance activities, some quality metrics must be there. One of the metrics includes the defect removal efficiency of each quality control activity, product quality and the defect density. Environment of system-based requirements:

00:42:01:23 - 00:42:32:17

Unknown

Ultimately, a Web application is to be embedded into some target system. Its interaction with the older systems or some new hardware is also to be focused upon. These are also requirements of a system related to it operational needs. Graphical User Interface-related requirements: Users interact with the help of graphical user interfaces only. The graphical user interfaces or GUIs include a form also.

00:42:33:01 - 00:43:00:01

Unknown

The front-end design is as much important as is the backend design. It is suggested that the users should help in the design of scenarios for specific tasks.

 It should be a usage-centric design approach so that it is easy for the end users of the Web site to use that application. Evolution requirements: Web applications are developed using spiral model.

00:43:00:14 - 00:43:28:16

Unknown

This is because they are getting evolved every day and every hour. Web developers must take care of all this. The future capabilities, future security requirements, future workloads, etc. must also be considered. Constraints on the project: Many restrictions work on a project while it is being developed like managerial constraints related to its cost, project’s time and the resource requirements.

00:43:29:01 - 00:44:08:24

Unknown

Technical limitations, following the standards, maintenance part, deployment constraints, operational constraints, legal constraints, etc. also affect a Web project. Learning Outcome Number Five. The Summary. By the end of the chapter, student should be able to differentiate types of requirements engineering by distinguishing to nine types of requirements engineering. Learning Outcome Number Six. Describe the notations and tools for requirement engineering. Notations and tools for requirement engineering. Notations for requirement engineering.

00:44:09:11 - 00:44:47:28

Unknown

Many methods are available for showing all of the requirements gathered. Some methods include:

 Stories, Unique Identifier given to all of the requirements, Use case method and standards like IEEE SRS Standard Eight Three Zero. Tools for requirement engineering. Analysis tools help a software engineer in creating system models. These models contain a representation of data, function and behavior as well as classify it as data, architectural, procedural and interface design.

00:44:47:28 - 00:45:30:28

Unknown

So, analysis tools provide quicker and better solutions so that errors do not propagate into the design phase. The followings are the samples of case tools. Structured Analysis, Structure Design Editors, Compilers, Debuggers, Code generators; Report generators; Documentation generators; Configuration management; Defect tracking; Collaboration tools; Reverse engineering; Metric analyzers; Catalyze for project management; Cost Xpert tool for Web project’s cost estimations; and Cradle for system analysis, design, coding and documentation.

00:45:31:20 - 00:46:04:13

Unknown

As far as the Web engineering is concerned, we can even invite Internet users to participate in Web surveys. That's the end of Learning Outcome Number Six. So, by the end of the chapter, students should be able to describe the notations and tools for requirement engineering by identifying requirement engineering representations and methods, and also to list tools for requirement engineering. Conclusion.

00:46:04:13 - 00:46:38:19

Unknown

Chapter Conclusion. The process of gathering, analyzing, categorizing and modeling the requirements of web users is known as requirement engineering. It discusses the requirements of the Web application based projects. It is mandatory, otherwise certain requirements are missed out and result in customer dissatisfaction. This is the main reference of this chapter. End of Chapter Two. Thank you.