and new requirements for the new system can be identified.System archaeologySystem archaeology is a technique that extracts information required tobuild a new system from the documentation or implementation (code)of a legacy system or a competitor’s system. The technique is oftenapplied when explicit knowledge about the system logic has been lostpartially or entirely. By analyzing existing code, the requirements engi-neer ensures that none of the functionalities of the legacy system willbe overlooked and the system logic of the legacy system is elicitedanew. This method leads to a large amount of very detailed require-ments and is very laborious. However, system archaeology is the onlytechnique that can ensure that all functionalities of the legacy systemwill be implemented in the new system. When it becomes obviouslyapparent that the legacy system and the new system differ in function-ality, additional elicitation techniques, e.g., creativity techniques, mustbe applied early on.Perspective-based readingPerspective-based reading (see section 7.5.4) is applied when docu-ments need to be read with a particular perspective in mind, e.g., theperspective of the implementer or the tester. Aspects that are containedin the document but do not pertain to the current perspective areignored. This allows for an analysis that is strictly focused on particularparts of the existing documentation. This way, detailed, technology-related or implementation-related aspects can be separated from essen-tial operational aspects that are relevant for the successor system.ReuseReuse: Requirements that have been previously compiled and broughtup to a certain quality standard can be reused. In order to do that, therequirements are stored in a database, for instance, and kept availableat the required level of detail for reuse. Through reuse, the costsinvolved with the elicitation procedures can be significantly reduced.
Subscribe to view the full document.
3.3Elicitation Techniques293.3.5Observation TechniquesQuestion observations and optimize processes.When domain specialists are unable to spend the time needed to sharetheir expertise with the requirements engineer, or are unable to expressand denote their knowledge, observation techniques are helpful. Duringobservation, the requirements engineer observes the stakeholders whilethey go about their work. The requirements engineer documents all stepsand thus elicits the processes the system must support as well as potentialmistakes, risks, and open questions. All those are potential requirementsthat need to be formulated. The stakeholders can actively demonstratetheir knowledge in using the application or can remain passive, with therequirements engineer merely observing. The requirements engineerought to question the observed processes so that the situation as it shouldbe can be established. Otherwise, she is at risk of documenting outdatedtechnological decisions and suboptimal processes (i.e., the situation as isand not as it should be). As the requirements engineer is an external
As a current student on this bumpy collegiate pathway, I stumbled upon Course Hero, where I can find study resources for nearly all my courses, get online help from tutors 24/7, and even share my old projects, papers, and lecture notes with other students.
Temple University Fox School of Business ‘17, Course Hero Intern
I cannot even describe how much Course Hero helped me this summer. It’s truly become something I can always rely on and help me. In the end, I was not only able to survive summer classes, but I was able to thrive thanks to Course Hero.
University of Pennsylvania ‘17, Course Hero Intern
The ability to access any university’s resources through Course Hero proved invaluable in my case. I was behind on Tulane coursework and actually used UCLA’s materials to help me move forward and get everything together on time.
Tulane University ‘16, Course Hero Intern
Ask Expert Tutors
You can ask 0 bonus questions
You can ask 0 questions (0 expire soon)
You can ask 0 questions
(will expire )