The 4 + 1 View Model is a predefined set of views for organizing the design and architecture of a system. It was developed in 1995 by Philippe Kruchten, formerly the Director of Process Development at Rational Software.
The 4 + 1 View Model gets its name from the 4 primary views and 1 supporting view that are used to capture and communicate different aspects of the system.
The 4 primary views are:
► Logical View: this view describes the functionality of the system in terms of its static structure and dynamic behavior.
► Development View: this view describes the system from a programmer’s perspective and is concerned with the organization of physical code, its main modules, and their dependencies.
► Process View: this view focuses on the runtime behavior of the system and the elements of the system that relate to process performance. It includes aspects important to scalability, throughput, and process response times to name a few.
► Physical View: this view shows the system from a system engineer's point-of-view. It is concerned with the deployment of software components across the physical architecture including computers and devices , as well as communication between these components.
The 1 supporting view is:
► Use Case View: this view describes the functionality of the system from the perspective of external actors.
For any new piece of work a BA (business analyst) needs to know
1. who are the key stakeholders (i.e. those who can kill the project)
2. what are the key stakeholders specific and measurable measures of success (i.e. their objectives) and what VALUE for each objective MUST be achieved in order for the project to be considered a success (e.g. increase sales per order value by 5%)
3. what are the key stakeholders unmeasured measures of success (i.e. their principles that they would like to see happen but aren't going to measure and so the project cannot be assessed by them - e.g. an intuitive solution)
4. what are the key stakeholders high level requirements (i.e. what capabilities do they expect the solution to deliver - e.g. the ability to offer add-on sales during the order taking process)
5. what is in scope of the work in terms of processes, organization units, locations, data, applications, technology
6. what is the scope of the work in terms of time, money, project resources (people and materials)
7. who will the stakeholders nominate for determining further high level requirements and detailed requirements (e.g. subject or domain experts, middle management of operational teams, etc)
The Yourdon introductory class on data flow diagramming used to (still does?) teach that 98% of the required work in requirements specification revolved around a single task. What is that task?
It depends, it depends, and it depends!
As for most questions in business analysis, there isn’t only one answer. Whose job is to create a class diagram depends on the purpose of the class diagram.
First of all, the question implies that there is only one class diagram for a given project: “The Class Diagram”. For the most part, this is not the case. On some projects there may be a multitude of class diagrams while in others there may be none.
Few analysts are brought on to a project at the very beginning. For those that are, they will often have a hand in creating some of the important documents that other analysts should reference when they first join.
First, get your hands on the project charter. The project charter, while high level, will provide critical information on the project.