Hi,
I am looking to develop a cinema booking scenario, I understand that I must document use cases for every part of the functionality of the system. I am going to have various sub-systems, for example, booking, user accounts, and order history. I am going to make an end product, fully functional in Visual Studio 2008 using ASP.net technologies.
My goal is to capture the requirements using a variety of diagrams from use case to activity diagram. However my question to you is, how do you get from capturing functional requirements to database/system design? Is there a particular method to deciding what approach of development to take?
I have read that I could document a customisation approach but it feels like scoping the system seems very distant to implementing it.
I am going to be using PayPal as my payment merchant and want to incorporate this into the design?
Hope you can guide me or suggest ways to improve/add to my design/scope/requirements analysis.
-Centurion
Hi centurian
I think You are mixing the Requirments with development. and also its too fast to analyse database/system design without elicitng the business reqts.
I think You are making a product . so Business need to be analysed first, which inturn Give inputs to architecture that u need for desin.
I think its better you elicate the Business Requirments w .r.t Business use cases, activity diagrams.
After eliciting this, U will get automatically clear picture of system boundaries
with Business architcture/boundaries, the data base/system design can be further derived
this inputs may help u
vijay
Centurion,
You need a complementary set of Information Requirements to go with your Functional Requirements.
E.g. FR -- The system must be able to accept an Order from a Customer.
Look for the nouns in your FRs for entities and attributes. Above, you have "Customer" and "Order" entities, and an impliciit relationship between them, so that is the start of of your information requirements. Most people use a data model of some kind, and then your Information Requirements are to support all the Entities, Attributes and Relationships in that model.
And if you get to this point, make sure to captuire your business rules separate from Functional and Information Requirements, and trace the rules to the requirements that need them.
Thank you for your swift reply Vijay,
I think the first port of call for me is to analyse the business. The current process is manual, basically the customer comes in and asks for a show, and the man behind the desk checks his tickets to see if he has any left. Payment is made, cash only and the customer goes into the screen to watch his/her movie.
So you are saying I should create business use cases? And activity diagrams?
Then once I have done this. I should be able to understand system boundaries? And then move onto system design?
Thank you for your post dwwright99,
I don’t think I have a problem with the database design aspect of things. I wanted to know what 'other' sorts of analysis I could do before design of the system. From yours and Vijay’s post I can understand that I must look at the business process, capture the functional requirements of the business and then do the same for functional requirements for the system?
brought to you by enabling practitioners & organizations to achieve their goals using: