MBA management

Requirements Engineering


Requirement engineering is a sub discipline of systems engineering and software engineering that is concerned with determining the goals, functions, and constraints of hardware and software systems. Software requirements engineering is the process of determining what is to be produced in a software system.

Requirement Engineering process


In developing a complex software system, the requirements engineering process has the widely recognized goal of determining the needs for, and the intended external behavior, of a system design. This process is regarded as one of the most important parts of building a software system. The hardest single part of building a software system is deciding what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. In the process of requirements engineering it is often difficult to state the real ‘what’ level of a system because one person’s ‘how’ may be another person’s ‘what’ and conversely. In this perspective, the requirements engineer faces a complex problem, in meeting the needs of the customer and at the same time meeting the needs of the designer.

Requirements engineering is an important aspect of any software project, and is a general term used to encompass all the activities related to requirements. The four specific steps in software requirements engineering are:

• Requirements elicitation
• Requirements analysis
• Requirements specification
• Requirements validation

Requirements Elicitation (Gathering)


equirements elicitation is a communication process between the parties involved and affected in the problem situation. The tools in elicitation are meetings, interviews, video conferencing, e-mails, existing documents study and facts finding. More than 90-95% elicitation should be complete in the initiation stage while the balance 5% is completed during the development life cycle. The requirements are gathered from various sources. The sources are:

• Customer (Initiator)
• Stakeholders
• Secondary Users
• Primary Users
• End Users

Fact Finding: Study of the organization where problem situation exists. Define the problem scope and study the people structure and existing system structure. Understand issues and concerns.

Requirements Gathering: Collect information from the viewpoint of various user sources about what is to be build and why, and the key expectations from the solution.

Evaluation: Evaluate different views for consistency, agreements, disagreements, and the reasons for such requirement. In the process total list of requirements would be rationalized. The process firms up, finalizes and resolves the conflict, if any in requirement statement.

Prioritization: In this process, requirements are prioritized on some criteria. The criteria could be a development sequence, customer implementation need, benefits to the organization, and so on. The prioritization is generally customer-centric, meeting customer requirements.

Consolidation: In this process prioritized requirements are put together in sequence and structures keeping in mind the ultimate solution goal. The end of consolidation results into a complete document (RDD).

The Requirements Engineering results are best achieved when persons(s) involved in this exercise have

• Domain knowledge
• Application Knowledge
• Fair understanding of the technology, its merits and limitations
• Good business communication skills
• Conflict resolution skills
• Conceptual and visualization skills to model the solution
• Grasp of customer and its business environment.

Requirements Analysis


In the earlier phase of requirements gathering, a broad understanding and agreement is reached and the list of requirements is ready for consolidation. In this phase, each requirement is analyzed from the point of view of validity, consistency and feasibility for firm consideration in the RDD and then in SRS. Validity confirms its relevance to goals and objectives, consistency confirms that it does not conflict with other requirements but supports others where necessary. Feasibility ensures that the necessary inputs are available without bias and error, and technology support is possible to execute the requirement as a solution. This portion of the analysis confirms the place of the requirement in RDD on its own and along with others.

The second portion of analysis attempts to find for each requirement, its functionality, features and facilities and the need for these under different conditions and constraints. Functionality states ‘how to achieve the requirement goal.’ Features describe the attributes of functionality and facilities provide its delivery, administration and communication to other systems.

Requirements Specification


Software Requirements Specification (SRS) is written at the end of requirement elicitation and analysis modeling. The SRS is written in a text narrative, supported by graphical models, system charts, and high-level pseudo programs in natural English language. SRS should be written for all requirements, small, large, simple or complex, including the obvious ones. SRS is based on approval RDD.

A good SRS documents has certain characteristics that must be present to qualify as a good. The characteristics are:

• Clarity
• Consistency
• Feasibility
• Completeness
• Modifiability
• Testability
• Correctness
• Traceability

Clarity: SRS is clear when it has a single interpretation for the author (analysis), the user, the end user, the stakeholder, the developer, the tester and the customer. This is possible if the language of the SRS is unambiguous. Clarity can be ascertained after reviewing the SRS by a third party. It can be enhanced if SRS includes diagrams, models and charts.

Completeness: SRS is complete when it is documented after

• The involvement of all types of concerned personnel
• Focusing on all problems, goals and objectives, and not only on functions and features
• Correct definition of scope and boundaries of the software and system

Structuring, labeling, maintaining minimum redundancy are the essential features to increase the modifiability of SRS.

Traceability: Traceability from specification to solution, and from solution to specification is very important. This characteristic facilitates an understanding of the effect on various functions and features, if modification is the requirement. Secondly, if an error occurs in testing, it’s a cause analysis is possible through traceability. With traceability, navigating through test plan, test case, test results, design, and architecture source code is easily possible.

Feasibility; RDD-SRS needs to be confirmed on technical and operational feasibility. SRS many times assumes use of technology and tools based on the information given by their vendors. It needs to be confirmed whether the technology is capable enough to deliver what is expected in SRS. The operational feasibility must be checked through environment checking. It is assumed in SRS. The operational feasibility must be checked through environment checking. It is assumed that sources of data, user capability, system culture, work culture and such other aspects satisfy the expectations of the developer. These must be confirmed before development launch.

Testability: SRS should be written in such a way that it is possible to create a test plan to confirm whether specifications can be met and requirements can be delivered.

• Considering functional and non-functional requirements
• Determining features and facilities required for each requirements
• Ensuring that ‘users’ and’ stakeholders’ freeze the requirement

Correctness: The requirements are termed as correct if they have a link to goals and objectives. The requirement and its specification through the software system should achieve the business goals and solve managerial and operational problems. A requirement and its functions and features are considered correct when it is most efficient and effective, and when it is considered valid by all concerned.

Consistency: Consistency in SRS is essential to achieve correct results across the system. This is achieved by

• Use of standard terms and definitions
• Consistent application of business rules in all functionality
• Use of data dictionary

Lack of consistency results in incorrect SRS and failure in deliverables to customer.

Modifiability: The need to modify occurs almost throughout the life of a software development process. To facilitate the modifications and keep track of them, RDD and SRS are documented in a structured manner. The helps to trace any detail easily, and modification is done at all places where necessary.

Software Requirement Specification(SRS) template


1. Introduction

1.1 Background
1.2 Purpose of the Document
1.3 Structure of this Document
1.4 Terminology Used
1.5 Convention Used in this Document
1.6 Other Documents Referenced

2. System descriptions

2.1 Current Situation Overview
2.2 Problems Faced in the Current System
2.3 Goals of the Proposed System
2.4 Overview of the Proposed System
2.5 User Characteristics
2.6 Assumptions Made

3. Functional requirements

3.1 Partitioning of the Functionality
3.2 Function/ module----1
3.2.1 Description of the Function (using representations/models as necessary)
3.2.2 Goals achieved
3.2.3 Labeled/enumerated Requirements
3.3 Function/Module—2
3.3.1 Description of the Function (using pre-presentations/models as necessary)
3.3.2 Goal achieved
3.3.3 Labeled / Enumerated Requirements
3.4 Function/ Model-3

4. Non-Functional Requirements

4.1 Performance
4.2 Resource Utilization efficiency
4.3 Security
4.4 Safety
4.5 Capacity
4.6 Interfaces
4.7 Availability
4.8 Reliability
4.9 Accuracy
4.10 Reusability
4.11 Ease of Use
4.12 Interoperability
4.13 Portability
4.14 Privacy
4.15 System Administration ease
4.16 Expandability
4.17 Maintainability
4.18 Testability

5. Project Requirements (optional)

5.1 Size Estimate
5.2 Effort Estimate
5.3 Cost Estimates
5.4 Schedules
5.5 Development Platform
5.6 Acceptance Criteria and procedures

Appendices

A. Pending Issues
B. Glossary
C. Index

Work Breakdown Structure (WBS)


A Work Breakdown Structure (WBS) is used to break the RDD into smaller units or components for planning and budgeting and for controlling costs, resources and efforts. WBS should be detailed enough to monitor and track the progress of development. A good WBS is the one that is evolved after considering a development strategy and an implementation strategy, and which is synchronized with steps in the software development cycle.

Another good characteristic of WBS is its mapping to RDD and SRS . WBS should cover complete SRS for execution. WBS should be SRS- oriented and not task oriented.

WBS is a hierarchy of elements that decomposes the software development plan, based on RDD< into discrete work tasks. It should provide information on

• Inclusion of significant, critical work elements traceable to SRS and RDD
• Responsibility to achieve results
• Framework for scheduling, budgeting , monitoring and tracking for control of costs, efforts and schedule

The Parameters to build WBS


• System structure (using SSA OOSAD)
• Functions
• Organizational Units
• Life Cycle Phases

WBS can be built using these parameters

• System Structure:
If the system is broken into modules then they become the anchor to build WBS. This can be further linked to the delivery and implementation plan.

• Functions:
If the system is largely function driven, then WBS can be built around its application, which is designed to deliver functions.

• Organizational Units:
If the system can be visualized after modeling by structure and or functions into organizational units, then WBS can be anchored onto organizational units.

• Life cycle phases

• Disregarding the earlier three parameters, one can follow the life cycle phase and build WBS for each phase starting from inception till delivery to the customer.
The choice of WBS parameters largely depends upon the nature. Complexity and the development and implementation strategy.

WBS characteristics


• Each WBS is a well- defined statement , having specific goals to be achieved
• The activities in WBS are standard life- cycle activities, which when completed achieve the goal
• Each WBS has a milestone, suggesting a goal that can be traced back to SRS and RDD
• Goals and milestones should be quantifiable, measurable and controllable
• The breakdown of WBS into sub-activities should be such that it’s scheduling is easier, resource allocation is clearly possible, and responsibility to complete the activity can be fixed with an individual
• The activities are such that their performance can be measured to control planned efforts, resources, costs and time allocation

Stakeholder


Stakeholders are persons or organizations (e.g., customers, sponsors. The performing organization, or the public), who are actively involved in the project or whose interests may be positively or negatively affected by the performance or completion of the project. Stakeholders may also exert influence over the project, its deliverables, and the project team members. The project management team must identify both internal and external stakeholders in order to determine the project requirements and expectations of all parties involved. Furthermore, the project manager must manage the influence of the various stakeholders in relation to the project requirements to ensure a successful outcome.

Stakeholder Identification


A major new emphasis in the 1990s was a focus on the identification of stakeholders. It is increasingly recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include:

• Those organizations that integrate ( or should integrate) horizontally with the organization the analyst is designing the system for
• Any back office systems or organizations
• Senior management.

Stakeholders are numerous and sometimes difficult to identify. The broad view of stakeholder identification focuses on a stakeholder’s ability to influence organizations behavior, direction, process or outcome, and focuses on the urgency, power, and legitimacy of the stakeholder in question, process or outcome, and focuses on the urgency, power, and legitimacy of the stakeholder in question. However, because each type of stakeholder has a different legal, economic, and social relationship to a particular project, a general stakeholder identification approach may not be too helpful in defining and explaining specific obligations of managers to stakeholders.

Understanding Stakeholders


Stakeholder analysis helps project managers and their advisors to assess a project environment , and to inform the organizations negotiating position in project talks. More specifically, undertaking a stakeholder analysis will:

• Draw out the interests of stakeholders in relation to the problems which the project is seeking to address or the purpose of the project

• Identify conflicts of interests between stakeholders, which will influence the organizations assessment of a projects risks before resources are committed 9 which is crucial for proposed projects)

• Help to identify relations between stakeholders which can be built upon, and may be enable coalitions of project sponsorship, ownership, and co-operation

• Help to assess the appropriate type of participation by different stakeholders, at successive stages of the project life cycle.

As previously pointed out there are numerous approaches to stakeholder analysis, ranging from the formal to informal, comprehensive to superficial. The most common methods employed are:

The Classification and Characteristics of Stakeholders


Once stakeholders are identified, they have to be characterized. In order to characterize stakeholders, thy need to be described, understood, and their roles and interaction need to be elaborated. In organizations that are traditional project management methods such as PRCCINCE 2 . Stakeholders are normally defined as direct ( primary and secondary) and indirect ( external and extended). Those directly affected by a proposed project are clearly among the key stakeholders. They are the ones who stand to benefit or lose from the organizations operations or who warrant redress from any negative effects of such operations. It is these directly affected stakeholders, who are the most significant and occasionally the most difficult to identify and involve in participatory efforts. Who are the most significant and occasionally the most difficult to identify and involve in participatory efforts. Although in traditional software projects they tend to be pulled from a narrow technical issues are properly considered. Many individuals or institutions may be indirectly involved or affected because of their technical expertise or public and private interest in organizational policies or programs, or they may b linked in some way to those who are directly affected. Such stakeholders may include various intermediary or representative organizations, private sector business, and technical and professional bodies. For project managers identifying and enlisting the right intermediary groups can and does prove difficult at times and in some situations can turn out to be a process of trial and error.

The Involvement of Stakeholders in Project


One of the very first conversations that need to take place between the project manager and the stakeholders is how they view the issue, challenge, or opportunity that has brought them together. Strikingly different emphases can emerge from this discussion. For software design groups, the emphasis may be on how to conserve costs over the long term. For the customer, the emphasis may be on how to improve their working processes or preserve their culture. They may or may not view the project central to these goals. So two different groups may in fact share similar views on the issue but express their objectives in different ways.

Any differences in perception and definition of the central goal and objectives need to be identified and addressed before the dialogue can move forward in a meaningful way. This is a key moment, as the stakeholders decide whose objectives will be at the heart of the venture, and whose will be less central. Next , the stakeholders must decide how to frame the central issues and tasks of a participation effort. willingness to be flexible about how the overall task is framed will be key to securing the collaboration of a range of stakeholders. This negotiation toward participation can be expected to take some time. It may also result in some stakeholders opting out of the participation process.

Stakeholder Interviews


Stakeholder interviews are a common method used in requirement analysis. These interviews may reveal requirements not previously envisaged as being within the scope of the project, and requirements not previously envisaged as being within the scope of the project, and requirements may be contradictory. However, each stakeholder will have an idea of their expectation or will have visualized their requirements.

Use case


A use case is a technique for documenting the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with thee end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by requirements engineers and stakeholders.

Use cases are deceptively simple tools for describing the behavior of software or systems. A use case contains a textual description of all of the ways which the intended users could work with the software or system. Use cases do not describe any internal working of the system, nor do they explain how that system will be implemented. They simply show the steps that a user follows to perform a task. All the ways that users interact with a system can be described in this manner.

Quality function deployment


Quality Function deployment ( QFD) is a technique for requirements engineering borne out of the quality movement. It did not originate as a requirements engineering technique, but rather as a systematic method for translating customer requirements into specific product design targets. The first Products were non-software such as shipyard products and automobile body parts. The concept works well with software because of the importance of the customer role in both traditional QFD industries and in software engineering. Including the customer is one of the surest ways of improving the likelihood of a successful software project.

Benefits of quality function deployment


The primary benefits of QFD are summarized:

Benefit   Rationale
Improved Customer satisfaction   This is a result of using QFD since the first input, and the driving force behind the rest of the process, is the voice of the customer. The QFD process actually refers to the “verbatim” comments from the customer as the starting point , and then provides a mechanism for translating these into design targets.
     
Reduced Development Time   This is mostly the result of concurrent engineering that is, using cross-functional teams.
     
Improved Internal Communications   Using cross-functional teams also means that there is less communications overhead, and less likely that one conversation in a serial chain of several conversations inadvertently misinterprets one of the inputs.
     
Better Documentation of Key Issues   The quality charts (Home of quality) provides an excellent documentation mechanism for key issues. In addition , the quality chart links these key issues to voice- of- the –customer concerns. This gives us a better idea of what a “key issue” is to the customer, knowledge that is powerful in terms of maintaining an excellent working relationship with the customer.
     
Save Money   The reduced development time leads to time savings, and money savings.


Additional benefits include improved morale and organizational harmony, improved efficiency, reduction in design changes, increased competitiveness, high market acceptance, and making it easier to identify problems with the development process. Many of these benefits come from the simple inclusion of the customer, and the feedback that the customer provides during the initial stages of a QFD effort. This feedback provides the focus for the team and they have a sense that they are all working towards a common goal. This is a powerful mindset for people to have on a project.

Modeling for Analysis


Modeling is the analysis tool used to look at a situation from different perspectives, with the objective of understanding and reducing ambiguity.

A modeling tool is applied mainly in two areas: functional and behavioral. Function is a system made of input- process – output. When function is executed, an event takes place. Further a function may be a set of several sub- functions. The objective of functional modeling is to understand clearly all functions identified in the RDD and SRS and ascertain the relationships among them.

The next important modeling application is in the behavior of various functions. A function is activated by an external stimulus. A function may remain in one state till it is altered by the stimulus. Behavior modeling helps to identify the stimuli, and the conditions in which they will be triggered to activate the function, moving it to the next state.

Information analysis, partitioning and modeling are three important analysis tools which help the developer to understand the situation ( system or problem), then to design a solution and, further, to build development and implementation strategies, Amongst these three, more prominently used by all is modeling for analysis. Information analysis and portioning support modeling. There is different modeling tools evolved for different purposes. The modeling tools developed are applicable to both types of approaches namely, Structured analysis ( SSAD) and Object Oriented Analysis (OOSAD), a modern approach to software development.

Both the analyses deal with data, function and behavior and different models to understand structure, flow, control and behavior of the system.

Modeling for Representation


In addition to analysis as application of modeling, modeling is used to represent through the abstraction process a larger complex scenario in business. During the course of requirement analysis and study, the developer or analyst must understand customer organization, business organization, critical processes and the way business is done. The in-depth understanding of these aspects provides much deeper insight into customer’s business, business processes, and also raises developer’s domain knowledge.

Business when it comes to software development is viewed as a system for the purpose of understanding, analysis and modeling. So, modeling as a method or technique is used to represent several aspects of customer organization and the business. Following models are useful to meet the need of understanding and representation of organization, Business, Systems, information flow and data structure.

• Customer organization model (people structure)
• Business organization model (function structure)
• Business system model (system structure)
• Business process model (process structure)
• Business entity relation model (entity relation structure)
• Information flow model (information flow structure)
• Data structure model (data structure)

In all these models entities are shown in structure that indicates hierarchy, relationship and direction of flow and control. The understanding of these finer points of business helps in re-engineering, system engineering, and design and architecture building of the software.

Validating Requirements


Validation is concerned with checks for omission, conflicting requirements, and ambiguities. Its goal is to seek out and correct problems before resources are committed to implementing the requirements. It seeks to certify that the requirements meet stakeholders’ intentions and ensure that they define the right system. Validation is the process of determining the degree to which a model, simulation, or federation of models and simulations , and their associated data are accurate representations of the real world from the perspective of the intended use(s).
Copyright © 2015 Mbaexamnotes.com         Home | Contact | Projects | Jobs

Review Questions
  • 1. What do you mean by requirements engineering? What are the processes involved in it?
  • 2. What is WBS? What are the parameters of WBS? State its characteristics.
  • 3. Who is a stakeholder? How will you identify?
  • 4. How will you classify stakeholders of a project?
  • 5. What is the involvement of stakeholders in a project?
  • 6. Write short notes on a) Use case b) QFD c) Validating requirements.
  • 7. What are the benefits of QFD? Explain.
Copyright © 2015 Mbaexamnotes.com         Home | Contact | Projects | Jobs

Related Topics
Requirements Engineering Keywords
  • Requirements Engineering Notes

  • Requirements Engineering Programs

  • Requirements Engineering Syllabus

  • Requirements Engineering Sample Questions

  • Requirements Engineering Subjects

  • EMBA Requirements Engineering Subjects

  • Requirements Engineering Study Material

  • BBA Requirements Engineering Study Material