You may have requirements specifications from previous or otherwise related systems for reference - these may be
helpful to walk through. Or you may have started using the Rational Unified Process some time after the project
With the group, walk through each requirement to find application behaviors or behavioral attributes. In general,
during the walkthrough, you should ignore explanatory information like introductions and general system descriptions.
Keep a list of all issues you identify and make sure someone is tasked to resolve each issue. You may need to make some
assumptions if a requirement is unclear. Keep track of these assumptions so you can verify them with the stakeholders.
Remember who wrote the requirements. Look for possible "misplaced requirements", meaning things that are out of scope
for the project. If you don't know whether something is a requirement, ask the stakeholders.
It is very effective to perform this type of walkthroughs by using any existing use-case outlines as a framework. Each
requirement needs to relate to at least one use case in your outline. If there is no use case to relate to, it is an
indication that either a use case is missing or that the requirement is misplaced.