http://foss2serve.org/index.php?title=Category:SE_Requirements_Engineering&feed=atom&action=historyCategory:SE Requirements Engineering - Revision history2024-03-28T12:32:08ZRevision history for this page on the wikiMediaWiki 1.18.1http://foss2serve.org/index.php?title=Category:SE_Requirements_Engineering&diff=12794&oldid=prevClif.kussmaul: Created page with "== SE/Requirements Engineering [1 Core-Tier1 hour; 3 Core-Tier2 hours] == The purpose of requirements engineering is to develop a common understanding of the needs, prioritie..."2018-10-15T13:38:17Z<p>Created page with "== SE/Requirements Engineering [1 Core-Tier1 hour; 3 Core-Tier2 hours] == The purpose of requirements engineering is to develop a common understanding of the needs, prioritie..."</p>
<p><b>New page</b></p><div>== SE/Requirements Engineering [1 Core-Tier1 hour; 3 Core-Tier2 hours] ==<br />
<br />
The purpose of requirements engineering is to develop a common understanding of the needs, priorities, and constraints relevant to a software system. <br />
Many software failures arise from an incomplete understanding of requirements for the software to be developed or inadequate management of those requirements.<br />
<br />
Specifications of requirements range in formality from completely informal (e.g., spoken) to rigorously mathematical (e.g., written in a formal specification language such as Z or first-order logic). <br />
In practice, successful software engineering efforts use requirements specifications to reduce ambiguity and improve the consistency and completeness of the development team’s understanding of the vision of the intended software. Plan-driven approaches tend to produce formal documents with numbered requirements. <br />
Agile approaches tend to favor less formal specifications that include user stories, use cases, and test cases.<br />
<br />
=== Topics: ===<br />
<br />
==== [Core-Tier1] ====<br />
* Describing functional requirements using, for example, use cases or users stories<br />
* Properties of requirements including consistency, validity, completeness, and feasibility<br />
<br />
==== [Core-Tier2] ====<br />
* Software requirements elicitation<br />
* Describing system data using, for example, class diagrams or entity-relationship diagrams<br />
* Non-functional requirements and their relationship to software quality (cross-reference IAS/Secure Software Engineering)<br />
* Evaluation and use of requirements specifications<br />
<br />
==== [Elective] ====<br />
<br />
* Requirements analysis modeling techniques<br />
* Acceptability of certainty / uncertainty considerations regarding software / system behavior<br />
* Prototyping<br />
* Basic concepts of formal requirements specification<br />
* Requirements specification<br />
* Requirements validation<br />
* Requirements tracing<br />
<br />
=== Learning Outcomes: ===<br />
<br />
==== [Core-Tier1] ====<br />
<br />
1. List the key components of a use case or similar description of some behavior that is required for a system. [Familiarity]<br />
<br />
2. Describe how the requirements engineering process supports the elicitation and validation of behavioral<br />
requirements. [Familiarity]<br />
<br />
3. Interpret a given requirements model for a simple software system. [Familiarity]<br />
<br />
==== [Core-Tier2] ====<br />
<br />
4. Describe the fundamental challenges of and common techniques used for requirements elicitation. [Familiarity]<br />
<br />
5. List the key components of a data model (e.g., class diagrams or ER diagrams). [Familiarity]<br />
<br />
6. Identify both functional and non-functional requirements in a given requirements specification for a software system. [Usage]<br />
<br />
7. Conduct a review of a set of software requirements to determine the quality of the requirements with respect to the characteristics of good requirements. [Usage]<br />
<br />
==== [Elective] ====<br />
<br />
8. Apply key elements and common methods for elicitation and analysis to produce a set of software requirements for a medium-sized software system. [Usage]<br />
<br />
9. Compare the plan-driven and agile approaches to requirements specification and validation and describe the<br />
benefits and risks associated with each. [Familiarity]<br />
<br />
10. Use a common, non-formal method to model and specify the requirements for a medium-size software system. [Usage]<br />
<br />
11. Translate into natural language a software requirements specification (e.g., a software component contract) written in a formal specification language. [Usage]<br />
<br />
12. Create a prototype of a software system to mitigate risk in requirements. [Usage]<br />
<br />
13. Differentiate between forward and backward tracing and explain their roles in the requirements validation<br />
process. [Familiarity]<br />
<br />
[[Category:ACM Body of Knowledge]]</div>Clif.kussmaul