REQUIREMENT
ENGINEERING
COURSE:
ANALYSIS & DESIGN OF SOFTWARE SYSTEM
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Requirements Engineering and Software Analysis, Lecture notes of System Analysis and Design
This essential academic resource provides an in-depth analysis of the Requirements Engineering (RE) cycle within the software development process. It details the seven fundamental tasks of RE—inception, elicitation, elaboration, negotiation, specification, validation, and management—explaining how they serve as a critical bridge between initial communication and final system construction. Readers will gain professional insights into identifying diverse stakeholders, managing conflicting viewpoints, and navigating common elicitation pitfalls such as scope volatility and communication barriers. Perfect for students and engineers, these notes offer practical strategies for establishing project groundwork using context-free questioning and collaborative negotiation techniques.
Typology: Lecture notes
2023/2024
1 / 24
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Requirements Engineering and Software Analysis and more Lecture notes System Analysis and Design in PDF only on Docsity!
REQUIREMENT
ENGINEERING
COURSE: ANALYSIS & DESIGN OF SOFTWARE SYSTEM
REQUIREMENT ENGINEERING
- (^) The broad spectrum of tasks and techniques that lead to an understanding of requirements is called requirements engineering.
- (^) From a software process perspective, requirements engineering is a major software engineering action that begins during the communication activity and continues into the modeling activity.
- (^) It must be adapted to the needs of the process, the project, the product, and the people doing the work.
- (^) Requirements engineering builds a bridge to design and construction.
RE TASKS
- (^) It encompasses seven distinct tasks:
- (^) Inception,
- (^) Elicitation,
- (^) Elaboration,
- (^) Negotiation,
- (^) Specification,
- (^) Validation,
- (^) Management.
- (^) It is important to note that some of these tasks occur in parallel and all are adapted to the needs of the project.
RE TASKS
- (^) Inception —ask a set of questions that establish …
- (^) basic understanding of the problem
- (^) the people who want a solution
- (^) the nature of the solution that is desired, and
- (^) the effectiveness of preliminary communication and collaboration between the customer and the developer
- (^) Elicitation —elicit requirements from all stakeholders
- (^) Elaboration —create an analysis model that identifies data, function and behavioral requirements
- (^) Negotiation —agree on a deliverable system that is realistic for developers and customers
ELICITATION & ITS PROBLEMS
- (^) It certainly seems simple enough—
- (^) ask the customer,
- (^) the users,
- (^) & others what the objectives for the system or product are,
- (^) what is to be accomplished,
- (^) how the system or product fits into the needs of the business,
- (^) and finally, how the sys-tem or product is to be used on a day-to-day basis.
- (^) Christel and Kang [Cri92] identify a number of problems that are encountered as elicitation occurs.
- (^) Problems of scope.
- (^) The boundary of the system is ill-defined or the customers/users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives.
ELICITATION & ITS PROBLEMS
- (^) Problems of understanding.
- (^) The customers/users are not completely sure of what is needed,
- (^) have a poor understanding of the capabilities and limitations of their computing environment,
- (^) don’t have a full understanding of the problem domain,
- (^) have trouble communicating needs to the system engineer,
- (^) omit information that is believed to be “obvious,”
- (^) specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable.
- (^) Problems of volatility.
- (^) The requirements change over time.
- (^) To help overcome these problems, you must approach requirements gathering in an organized manner.
NEGOTIATION
- (^) To reconcile these conflicts through a process of negotiation.
- (^) Customers, users, and other stakeholders are asked to rank requirements and then discuss conflicts in priority.
- (^) Using an iterative approach that
- (^) Prioritize requirements,
- (^) Assesses their cost and risk,
- (^) Addresses internal conflicts,
- (^) Requirements are eliminated,
- (^) Combined, and/or modified so that each party achieves some measure of satisfaction.
SPECIFICATION
- (^) In the context of computer-based systems (and software), the term specification means different things to different people.
- (^) A specification can be
- (^) a written document,
- (^) a set of graphical models,
- (^) a formal mathematical model,
- (^) a collection of usage scenarios,
- (^) a prototype,
- (^) or any combination of these.
REQUIREMENTS MANAGEMENT
- (^) Requirements for computer-based systems change, and the desire to change requirements persists throughout the life of the system.
- (^) Requirements management is a set of activities that help the project team - (^) identify, - (^) control, - (^) track requirements - (^) changes to requirements at any time as the project proceeds.
ESTABLISHING THE GROUNDWORK
STEPS TO ESTABLISH GROUNDWORK
- Identifying Stakeholders
- Recognizing Multiple Viewpoints
- Working toward Collaboration
- Asking the First Questions
1.IDENTIFYING STAKEHOLDERS
- (^) Sommerville and Sawyer [Som97] define a stakeholder as “anyone who benefits in a direct or indirect way from the system which is being developed.”
- (^) Some of the stakeholders are
- (^) Business operations managers,
- (^) Product managers,
- (^) Marketing people,
- (^) Internal and external customers,
- (^) End users,
- (^) Consultants,
- (^) Product engineers,
- (^) Software engineers,
- (^) Support and maintenance engineers, and others.
2.RECOGNIZING MULTIPLE VIEWPOINTS
- (^) There may be different stakeholders exist, the requirements of the system will be explored from many different points of view.
- (^) For example,
- (^) the marketing group is interested in functions and features that will excite the potential market, making the new system easy to sell.
- (^) Business managers are interested in a feature set that can be built within budget and that will be ready to meet defined market windows.
- (^) End users may want features that are familiar to them and that are easy to learn and use.
- (^) Software engineers may be concerned with functions that are invisible to nontechnical stakeholders but that enable an infrastructure that supports more marketable functions and features.
- (^) Support engineers may focus on the maintainability of the software.
2.RECOGNIZING MULTIPLE VIEWPOINTS
- (^) Each of these communities (and others) will contribute information to the requirements engineering process.
- (^) As information from multiple viewpoints is collected, emerging (rising) requirements may be inconsistent or may conflict with one another.
- (^) You should categorize all stakeholder information (including inconsistent and conflicting requirements) in a way that will allow decision makers to choose an internally consistent set of requirements for the system.