Deadline 14-12-2016

Perform the following tasks for the case study Library Management (UWON) :

1. Identify the objectives for the system-to-be.
2. Give three definitions.
3. Identify five domain properties.
4. Identify five system requirements.
5. Identify five software requirements.
6. Identify five non-functional requirements.
7. Identify five assumptions with their rationales.
8. Identify the actors.
9. Identify five use cases.
10. Give the detailed description for two use cases (name, actor(s), brief description, precondition, postcondition, basic flow, alternative flows)

In the following directives, the word element refers to any of the following: definition, domain property, system requirement, software requirement, non-functional requirement, assumption, use case.

• Don't repeat the elements that were presented during the lectures which are taken from the text book . • If you don't find the required number of elements in the description, than complete by elements from your choice.

• Avoid Sign Up and Sign In requirements and use cases.

 

 

KSU/CCIS/SWEDr. Mohsen DenguirSWE 503 Fall 2016SWE 503:Project DescriptionNovember 20, 2016Deadline: December 25, 2016Presentation: January 1, 2017Perform the following tasks for the case study Library Management:1. Identifythe objectivesfor the system-to-be.2. Givethree defnitions.3. Identifyfve domain properties.4. Identifyfve system requirements.5. Identifyfve soFtware requirements.6. Identifyfve non-Functional requirements.7. Identifyfve assumptionswith theirrationales.8. Identifythe actors.9. Identifyfve use cases.10. Givethe detailed description For two use cases(name, ac-tor(s), brief description, precondition, postcondition, basic ±ow,alternative ±ows)In the following directives, the wordelementrefers to any of the follow-ing: de²nition, domain property, system requirement, software require-ment, non-functional requirement, assumption, use case.•Don’t repeat theelementsthatwerepresentedduringthelectures.•If you don’t ²nd the required number ofelementsinthedescription,than complete byelements from your choice.•AvoidSign UpandSign Inrequirements and use cases.

Fundamentals of Requirements EngineeringAs we are concerned with the problem world, we need to consider both thesystem-as-is,tounderstand its objectives, regulating laws, deficiencies and limitations, and thesystem-to-be,to elaborate the requirements on the software-to-be accordingly together with assumptions onthe environment.The systems-to-be-nextIfwe want to build an evolvable machine in our problem world, we need to anticipate likelychanges at RE time. During software development or after deployment of the system-to-be,new problems and limitations may arise. New opportunities may emerge as the world keepschanging. We may then even need to consider more than two system versions and foreseewhat the next system versions are likely to be. Beyond the system-as-is and the system-to-be,there aresystems-to-be-next.Requirements evolution management is an important aspect of theRE process that will be discussed at length in Chapter 6.Requirements engineering: A preliminary definitionIn this setting, we may apprehend requirements engineering more precisely as a coordinatedset of activities for exploring, evaluating, documenting, consolidating, revising and adapting theobjectives, capabilities, qualities, constraints and assumptions that the system-to-be should meetbased on problems raised by the system-as-is and opportunities provided by new technologies.We will come back to those various activities in Section 1.1.6 and will have a much closer lookat them in subsequent chapters.1.1.2 Introducing our running case studiesTo make the nature of RE more apparent and more concrete, we will consider a varietyof case studies. The following descriptions are intended to set up the context in which ourrunning examples will be used throughout the book. They will also provide further insightsinto the scope and dimensions of the problem world. We should not consider them as problemstatements, but rather as fragmentary material collected from preliminary investigations of theproblem world (perhaps by use of the elicitation techniques discussed in Chapter 2).

Setting the scene

IIFundamentals of Requirements Engineering