Requirement Analysis Vs Requirement Engineering

Software Engineering Notes: Q1.Requirement Analysis? Q2.Requirement Engineering? - its Role in Software Development, types of Elicitation Phases. (Software Engineering all notes) [ Topic= Requirement Analysis Vs Requirement Engineering ]


Q1. Explain Requirement Analysis in the Requirement Engineering?

Ans. Requirement Analysis: Requirement Analysis is very important and essential activity after requirement elicitations. We analyze, refine the gathered requirements in order to make consistent and unambiguous requirements. This activity reviews all requirements and may provide a graphical view of the entire system.

After the completion of analysis, it is expected that the understandability of the project may improve. Various steps of requirement analysis are shown in figure.

Requirement Analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users.
Requirement Analysis is critical to the success of a development project. Requirements must be actionable, measurable, testable, related to identified business needs or opportunities and defined to a level of detail sufficient for system design. Requirements can be functional and non-functional.
[ Topic= Requirement Analysis Vs Requirement Engineering ]
[ Topic= Requirement Analysis Vs Requirement Engineering ]

Q2. What is the role of Requirement Engineering in software development. Explain all types of elicitation phase?

Ans. Requirement Engineering: Requirement describe the "what” of a system and not the "how". Requirements engineering produce a large document, written in natural language, contains a description of what the system will do without describing how it will do.

The input of the requirements engineering is the problem statement prepared by customer.

In engineering, a requirement is a singular documented need of what a particular product or service should be or perform. It is most commonly used in a formal sense in systems engineering or software engineering.

It is a statement that identifies a necessary attribute, capability, characteristic or quality of a system in order for it to have value and utility to a user.

In the classical engineering approach, sets of requirements are used as inputs into the design stages of product development. Requirements are also an important input into the verification process, since tests should trace back to specific requirements.

Requirements show what elements and functions are necessary for the particular project. The requirements development phase have been preceded by a feasibility study or a conceptual analysis phase of the project.

The requirements phase may be broken down into requirements elicitation (gathering, understanding, reviewing and articulating the needs of the stakeholders), analysis (checking for consistency and completeness), specification (documenting the requirements) and validation (making sure the specified requirements are correct).

Requirement in Software Engineering : Requirement Analysis

In systems engineering, a requirement can be a description of what a system must do, referred to as a functional requirement. This type of requirement specifies something that the delivered system must be able to do.

Another type of requirement specifies something about the system itself and how well it performs its functions. Such requirements are often called non-functional requirements or performance requirements' or 'quality of service requirements.'

Examples of such requirements include usability, availability, reliability, supportability, testability, maintainability and (if defined in a way that's verifiably measurable and unambiguous) ease-of-use.

A collection of requirements defines the characteristics or features of the desired system. A 'good' list of requirements generally avoids saying how the system should implement the requirements, leaving such decisions to the system designer.

Describing how the system should be implemented may be known as implementation bias or "solution engineering". However, implementation constraints (ask solution requirements) on the solution may be validly expressed by the future owner, for example for communality reasons with other owned products.

Types of Product Requirements : Requirement Analysis

Requirements are typically placed into following categories :
1. Functional requirements describe the functionality that the system is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities.

2. Non-functional requirements are the ones that act to constrain the solution. Non- functional requirements are sometimes known as quality requirements or utilities.

3. Constraint requirements are the ones that act to constrain the solution. No matter how the problem is solved the constraint requirements must be adhered to.

Non-functional requirements can be further classified according to the usability requirements, look and feel requirements. humanity requirements, performance requirements, maintainability requirements, operational requirements, safety requirements, reliability requirements or one of many other types of requirements.

In software engineering this categorization is useful because only functional requirements can be directly implemented in software. The non-functional requirements are controlled by other aspects of the system.

For example, in a computer system reliability is related to hardware failure rates and performance is controlled by CPU and memory. Non-functional requirements can in some cases be decomposed into functional requirements for software.

For example, a system level non-functional safety requirement can be decomposed into one or more functional requirements. In addition, a non-functional requirement may be converted into a process requirement when the requirement is not easily measurable.

For example, a system level maintainability requirement may be decomposed into restrictions on software constructs or limits on lines or code.

Important Process Steps

The quality of a software product is only as good as the process that creates it. Requirement engineering is one of the most important activity in this creation process. Without well written requirement specifications, developers do not know what to build, customers do not know what to expect and there is no way to validate that the built system satisfies the requirements.
Requirement engineering is the disciplined application of proven principles, methods, tools and notations to describe a proposed system's intended behaviour and its associated constraints.
This process constraints of four steps as shown in figure.

Requirement Elicitation:

In requirements engineering, requirements encitation is the practice of obtaining the requirements of a system from users, customers and other stakeholders. The practice also sometimes referred to as requirements gathering.

The term elicitation is used in books and research to raise the fact that good requirements cannot just be collected from the customer, as would be indicated by the name requirements gathering.

Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do. Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brain storming, use cases, role playing and prototyping.

Requirements elicitation is a part of the requirements engineering process, usually followed by analysis and specification of the requirements.

The real requirements actually resides in users mind. Hence, the most important goal requirement engineering is to find out what users really need. Users need can be identified only if we understand the expectations of the users from the desired software.

It is the activity that helps to understand the problem to be solved. Requirements are gathered by asking questions, writing down answers, asking other questions etc. Hence, requirements gathering is the most communications intensive activity of software development.

Requirements elicitation requires the team work of several groups of participants who have different background. There are some requirements elicitation methods as given below:

(1) Interviews:

After receiving the problem statement from the customer, the first step is to arrange a meeting with the customer. During the meeting or interview, both parties would like to understand each other.
The objective of conducting an interview is to understand the customers expectations from the software.

Both parties have different feelings, goals, opinions, vocabularies, understandings, but one thing is common that both wants the success of the product.

Interview may be open-ended or structured. In the open-ended interview, there is no preset agenda. Context free questions may be asked to understand the problem and to have an overview of the situation.

In structured interview, agenda of fairly open questions is prepared. Sometimes a proper questionnaire is designed for the interview.

#Selection of Stakeholder :

It will be impossible to interview of every stakeholder. Thus representatives from groups must be selected based on their technical experience, domain knowledge and accessibility.

There are several groups to be considered for conducting interviews:
(i) Entry level personnel.
(ii) Mid-level stakeholder.
(iii) Managers of other stakeholder.
(iv) Users of the software.

#Type of Questions in Interview :

Questions should be simple and short. It is important to prepare questions, but reading from the questionnaire is not desirable. We should be open for any type of discussion and any direction of the interview.

For Example: For the "Result Management System" we may ask the following questions :

(i) Are there any problems with the existing system?
(ii) Have you faced calculation errors in past?
(iii) What are the possible reasons of developing software?
(iv) What are the possible benefits of computerizing this system?
(v) Are you satisfied with current processes and policies?
(vi) What problems do you want this system to solve?

(2) Brainstorming Sessions :

Brainstorming is a group technique that may be used during requirement elicitation to understand the requirements. The group discussions may lead to new ideas quickly and help to promote creative thinking.

It is intended to generate lots of ideas, with full understanding that may not be useful. The theory is that having a long list of requirements from which to choose is far superior to starting with a blank stake.

Brainstorming has become very popular and is being used by most of companies. It promotes creative thinking, generates new ideas and provide platform to share views, understanding expectations and difficulties of implementation.

This group technique may be carried out with specialized groups like actual users, middle level managers or stakeholders.

After this session, a detailed report will be prepared and facilitator will review the report. Every idea will be written in simple English so that it conveys same meaning to every stakeholder, Incomplete idea may be listed separately and should be discussed at length to make them complete ideas, if possible. Finally, a document will be prepared which will have list of requirements and their priority.

[ Topic= Requirement Analysis Vs Requirement Engineering ]
[ Topic= Requirement Analysis Vs Requirement Engineering ]
[ Topic= Requirement Analysis Vs Requirement Engineering ]

Join us on Facebook, Instagram, and Twitter to get the latest study material. You can also ask us any questions.
Facebook = @allbcaweb
(click on it or search "allbcaweb" on Facebook)
Instagram = @allbcaweb
(click on it or search "allbcaweb" on Instagram)
Twitter = @allbcaweb
(click on it or search "allbcaweb" on Twitter)
Send us your query anytime about Optimization Techniques Notes!

[ Topic= Requirement Analysis Vs Requirement Engineering ]
[ Topic= Requirement Analysis Vs Requirement Engineering ]

External Links:-

1. Requirement Analysis. (click here)
2. Requirement Engineering. (click here)
[ Topic= Requirement Analysis Vs Requirement Engineering ]
[ Topic= Requirement Analysis Vs Requirement Engineering ]

No comments:
Write comment