Requirements Engineering is the starting activitiy in the software lifecycle. Goal of RE is to create a precise, natural-language-based specification for a software system, plus the maintenance of such a specification. A requirements document is supposed to bridge the "natural gap" between business side (purchaser) and IT side (contractor). Such a documents needs to be easily understandable by both sides, yet precise enough to serve as a base for coding software. RE is a sequel to "Anforderungsmanagement" (AM) in Master Computer Science (Software Engineering) study program, which is the predecessor of the Master of Digital Sciences. Both RE and AM will be taught jointly, until the Master Computer Science will expire.
#rollenzuweisungand click on
am. Then you see all channel(s) relevant for this module.
In this module, you learn how to analyse stakeholders, constraints, and goals for a planned IT system. You obtain requirements for an IT system using observations, conversations, and documents; all of which will be based on natural-language, and may contain implicit, potentially incomplete, and contradictory information, structure and formalize these information as requirements in a complete und consistent way. You need to prioritize these requirements for software design and implementation, and document the requirements as a specification for a waterfall or agile project.
As a requirements engineer or a business analyst on Master level I can collect and formalize requirements for a software system,
by me ...
so that I can instruct a (potentially external) development team in implementing the software system according to the requirements specification.
The module consists of two parts, which are executed in parallel.
The method trainings follow a process model explained on a dedicated page. Each subteam needs to pick a training block, and prepare the training. I will support you doing so.
In this course, each team will pick its own idea for a case study. So, your task in your subteam is: Think about an idea for a startup.
You will face the following situation in this course: You, together with a couple of collegues, play the National Lottery together. You never gave that much thought, but now you have actually won a staggering multi-million jackpot! After having bought houses and expensive cars, you jointly decide to invest the remaining 1 Million Euro into a startup that you will found together in your subteam (the teams A … E from 1) above).
You will discuss the ideas for that startup in your subteam, finally agree on one per subteam, and collect some ideas for it. This idea will be turned into a requirements document during this course.
We will use Jamstack-based webtool for documenting the various artefacts belonging to a requirement specification.
Each subteam will be provided with a repository containing the tool, as an empty framework (without content). An example (unfortunately in German) can be found here:
When working on the requirements specification for your case study, you (as a subteam) should prepare the following number of artefacts. The numbers are supposed to reflect realistic numbers (within limits). The numbers are my (rough) estimates based on experience. We assume that the software to be written fits in size to a startup (so in the ballpark of 1-2 person years).
|Artefact type||Min. number per subteam||A realistic number would be …||How do to compile these artefacts?||Available in RE Tool|
(each of the customer team should appear in a specific role)
|more than that, as many aspects aren’t covered here (e.g. funding)||talk to sponsors||yes|
|Stakeholder Role||4||probably more than that (see stakeholders)||define role(s) for your stakeholders, then analyse the other data (interview, workshops, survey)||yes|
|System Context Element||8||10-30||Just analyse all data sources (add if something comes up later)||yes|
|Goal||8||not more than 15-20 (“less is more”, as goals should be concise)||primary sources are the project description and the sponsor interview, maybe also workshop||yes|
|Interview||1||depends very much what kind of information collection works best; >1 … 10||conduct & evaluate interviews||yes|
|Glossary||16||10 - 30||whenever a business term comes up, define & add it (continuous activity)||Mon 9.5.|
|Domain Model||1||1||base it on your glossary (most important terms defining your domain appearing here)||Mon 9.5.|
|Workshop||1||0 - 10, really depends on the product, and the design approach||plan & conduct as per training||Mon 16.5.|
|Survey||1||0 - 1, depends where this makes sense; might be useful e.g. in case of an internal tool, or for a specific user group||plan & as per training||Mon 16.5.|
|Scenario||8||20 or more||base on the information you have, esp. workshop and interviews||Fri 20.5.|
|Persona||8||10||rule of thumb: create two personas per stakeholder role, based on your information collection||Fri 20.5.|
|Functional Requirement||24||50 - 75||take the essence from your scenarios and the overall information collection, align with goals||Fr 03.06.|
|Nonfunctional Requirement||4||10 - 20||don’t invent stuff - filter what was actually said in your sources||Fr 03.06.|
|Priorisation||1||1||apply to functional requirements||Fr 10.06.|
|Use Case||8||30 - 50||base them on the scenarions and the functional requirements||Fr 01.07.|
|Use Case Diagram||2||ca. 10||cluster the use cases appropriately||Fr 01.07.|
|User Story||16||ca. 100 (assumption 4 developers team, 1 year time)||assumption: this the first product backlog, so make UC small, and prioritize!||Fr 01.07.|
(1 per artefact type)
|2 - 5, depending on the design approach and the organizational culture; usually, requirements are compiled into one document||each customer team makes a formal review of the artefacts (see list above)||Fr 01.07.|
The grade for this module will is composed in the following way:
(more detailed criteria will follow)
In this workshop, I will provide you with a motivation for RE. We will sort out all organisational details in order to get the module going. You can read about the content in this slideset.
You are ready to start.
Trainings and todo definition for block 1 (Stakeholders, System Context, Goals). You can read about the content in this slideset.
You know how to analyze the context of a planned software system, and the todos for your team in the RE case study have been clarified.
The training for Block 2 deals with continuous activities, like glossary, domain model, status model, and quality assurance.
Informal requirements (block 3) comprise artefacts like scenarios and personas, which are not very highly formalized, and techniques to collect data for them. In this workshop, we start with the
Workshops conducted, todos for evaluation and documentation clarified
Completing requirement lists, and prioritizing them
All trainings done, todos defined