Hi All,
I have a question, if i have to draw a use case and write the description do i need to write like this
The requirement is
The user needs budget forecasting report, It has X X fields ( If its a report what kind of information do i need to ask the stakeholder? like peridoicity .. 1. the user logs on to XX( Basic Flow) 2. selects XX
3. The user is displayed XX results
It also has Alternate Flow
Please correct me
Roger
I've found use cases are not good for documenting report requirements. You can use a use case to describe the main flow and alternative paths of running the report, but you should use a report specification to describe whats on the report. Some of the sections you should include in a report specification are:
Hope that helps. Good luck.
Hi Irvine & All , Can you let me know what are some specific set of questions i can ask the stakeholder.
Discuss the importance and characteristics of software quality and explain how each of these characteristicsmight be measured.
Draw the primary activities of DRB, comment on the significance of each of these activities and the value that they offer to customers.
when you asking the customer you should concern on the main functionalities, and after that you asking him on each one more details (with seqauancial events).
and asking him on some of none-functional requirments upon your situation, becaouse there are many people failure in the requirment gatharing becaouse he/she didn't concern about the None-Functional requirmnets.
Explain how DRB might re-structure its upstream supply chain to achieve the growth required by DRB and totackle the problems that Dilip Masood has identified
when you asking the customer, you should be more spesific and accurate and you should know how you can explain most things directly.
Greetings Rogs,
there are 2 componets to your issue. 1) the report request (use case) and 2) the report GUI/Layout (display). the latter is normally in another specification.
here is an approach
Main Flow
1. the usecase starts when the user requests a forecast report
2. the system displays the request screen (see GUI-001)
3 the user selects a printer report (consolidated forecast Format REP-001) and the reporting period (start, end dates)
4. the system creates the forecast report
Alternate flow
3.1 the user selects the itemised report Format REP-002
3.2 the user selects a screen report (Format GUI-002, GUI-003)
-------------------------------------
Report/GUI interfaces layouts (in another specification)
Note; the consolidated and itemsised reports may have different layouts; and if they are displayed on screen they may be slightly different. Thus you may have four report format types.
REP-001 ... Layout
REP-002 ... Layout
GUI-002 ... Layout
GUI-003 ... Layout
brought to you by enabling practitioners & organizations to achieve their goals using: