The process of transcribing the human activities pertaining to, and the functions of the system implemented and or being proposed is that I will refer to as analysis.
The process of deciding how certain functions are to be supported by an implementation will be referred to as design. Design at a high level involves an architecture. Architecture refers to the available groupings of technologies which will support the implementation.
The first task of analysis involves the identification of domain experts. Domain experts are selected from the group of users directly associated with the proposed functionality. They are senior people who have been with the organization for a long time, and they are people who are able to separate the things they do, from the way that they do them. The first objective is to document what it is that is being done.
In coming up with the list of domain experts, will require collaboration with someone in the institution who has been expressly empowered to make available the time of people who are not necessarily reporting to him on a daily basis. A copy of the memo, or e-mail by which the executive grants this authority, should become a project artifact. If the person has not been explicitly blessed in this way by senior management, then don't walk -- run!
In selecting the sample set of domain experts, it is essential that representatives from all roles are selected. It is also essential that some redundancy, or overlap is allowed for.
Arrange for a "kick-off" meeting with the whole group, if possible. Describe what is being proposed, giving background and a high level description of why we are involved. Do not try to discern the requirements right there and then, but describe the process for determining those requirements, and the fact that they can be expected to be contacted in the near future for their input. Before the group is dismissed, ensure that a roster is created, with the person's name, official title, short description of what they do on a day to day basis, their phone number, e-mail address, and some indication of what office hours they normally keep.
In addition to the roster, try to get three additional documents: a company-wide phone list, and a map of where everyone sits, and a recent org chart. As well establish the protocol for moving between various parts of the organization. You may be able to get a temporary pass (highly recommended) or you may need to be escorted through certain "sensitive" parts of the organization. Make sure you have a place to sit for the duration of the on-site visit. This location requires a phone, and should be reasonably quiet. This may take the form of a cubicle, or a conference room. Conference rooms are handy since they are a pre-booked meeting room. It is a plus if you can have a LAN connection, preferably for your own laptop, but if you have a standard issue PC, then floppy transfers will work ok too. The time to arrange this is actually during the pre-site visit conference call.
It is time to prioritize the candidates. Consider whether any of the candidates would have information which might directly impact the architecture, these should be considered first. Next, consider those candidates that are close to core requirements. Finally, consider candidates which have either a primarily managerial role, or have involvement with peripheral functionality. Managers conversations will have a tendancy to spout the jargon but by be shy on functional details. Use management interviews as a sounding board for overall objectives, not as the source of core requirements.
Schedule times for individual interviews using these guidelines. The interviews should be grouped into time slots on either side of noon, in order to maximize the probablity of participation. Set aside time late in the afternoon and early in the morning for documentation. Do not book your interviews so close together that you do not have time to digest the one, before starting the next. It is suggested that interviews be booked into 45minute timeslots with 45 minutes between interviews for updating notes electronically. Under no circumstances should an interview exceed 75minutes. If during the course of a meeting you discover that the subject has not fully disclosed the aspects of the system which you feel are pertinent, then arrange for a follow-on meeting. Do not schedule interviews before noon on Mondays, nor after noon on Fridays -- for obvious reasons. Clearly, some people's schedules will imply that you need to stand on your head to fit them in; just don't forget the principles of documentation when you finally do squeeze them in.
Follow up each interview with a report. This is when the meeting took place, this is who was there, and these are the things that were said. This summary will consume less than 50 lines (i.e. will fit on a single printed page). Make sure that you record the names of people who the interviewee works with on a daily basis. If possible, e-mail these to the persons who were present in the conversation on the same day as the interview, at the very first opportunity. It is essential that they get an opportunity to augment the text with their own comments, and that these comments, if provided, become a part of the project documentation.
The interviews will be with individuals. On occasion it will be useful to have others present, but try to have as many of you as of them. That is: as many analysts as being analyzed. If you have too many subjects in the room, the facts will be coming fast and furious, and some points will get missed, or forgotten. Generally, the best ratio for these interviews has been two analysts, one charged with the line of questioning, the other with the transcription of the conversation, and one to two persons being interviewed at a given time.
It is quite likely, that as you progress through your interviews, you will be hearing recommendations of who to talk to about certain subjects. These should be followed up. Get the correct spelling of the name, and the contact information into your notes right there and then. Always record the attempts to follow up this contact in the interview report of the referer. The actual interview which results will, however, be documented as an interview in its own right.
Other than providing a few platitudes what can be said here? We are interested with process. We are interested in what is being done. The most natural language in which the user can describe things, is in terms of how he currently does it. In spite of using this as an efficiency, we need to keep in mind that it is function that we are after in the end.
Some companies may already have some existing process documentation. It is hard to resist the temptation not to rely on this verbatim. The problem is that it is difficult to ascertain how accurate, current and applicable any given primary document might be. If all of the above apply, then the next problem, that of digesting it, may be even more daunting. Try to get all primary documents in standard open electronic format if possible. This means get the documents in text or html. If graphical, use JPEG or PNG. If the primary documents are in MSFT Office, or in VISIO formats, i.e. applications which are ubiquitous, this might be a sensible, albeit, second choice.
Yes, ask the question about available "official" documentation! This will give you a sense of whether the thing being described to you is in fact a process. Chances are if there is no official documentation regarding a phase of work, then it is quite possibly not a process at all. Remember, in order for something to be a process it must be repeatable. Also, do not allow yourself to get overwhelmed if a mammoth repository of information is hurled in your direction. Focus on using the primary documents as a means of supporting the text of an interview, rather than as a source in its own right. In doing so get the referrer to point to sections of the cited primary documentation and record that information as a part of the report. Primary documentation which is cited, needs to become a project artifact. Also, remember to review the artifacts and comment on any discrepancies between what the doc says and what the interview reveals. The interview will be deemed definitive from a requirements perspective. If the primary document collection is extensive, you may need to add scope to the statement of work which accomodates adequate review of these notes.
Ask the domain expert:
Wrap up the meeting by thanking the candidate for his time, and asking whether he would be available for further questions by phone, or via e-mail. Then comes the scramble to transcribe the chicken scratches in your notepad into a coherent summary on your computer. Use point form, and informal text to describe the process. Pay attention to the nouns and verbs that were used.
Take the reports you have generated to date, and if they were done right, they should map fairly closely to use cases. A use case shall be generated for each role+application interaction. For a manual process try to capture main groupings of function as the "application". The groupings need to be intuitively determined. They might be grouped as result of a common set of data, manipulated by a user, or group of users sharing a function. Use cases are always written from the user's point of view.
Each use-case will be represented diagrammatically using the following
conventions. Each group of users performing a function is deemed a
role. Each role will be identified using the actor symbol. Label the
symbol using the name of the role from your problem domain reports.
For each interaction that a role has with an application, indicate using a line representing the communication. Each line represents bidirectional communications by default.
The association indicator is usually a verb, where as the name of the actor is a role and the application system are usually nouns. It is expressive to supply labels for the lines of communication, but not mandatory.
The purpose of the use-case is to demonstrate the interactions with functionality, to show who in the system is using it, and to agglomorate groups of function into a functional subsystems. It also provides a high level framework for which to place the scenarios.
Use many scenarios to describe specific instances of use-cases. Scenarios are time-ordered expressions, expressed using natural language. Use specific instance of data, wherever possible.
For each use-case, split the interactions based on natural breaks in time or in functionality. For example, if the interaction with the system involves credit validation for which the user leaves the application system and places a telephone call. After a significant period of telephone tag, the clerk receives the necessary information, at which time she returns to the in aforementioned interaction with the application system to finish the processing. These would be decomposed into three (or more) scenarios.
Use cases may also be split into scenarios using various data groupings.
... need to detail the process for scenario creation Use the vernacular of the problem domain wherever possible.
Milestone: need to get customer signoff of the use-cases and the scenarios.
Go through the documented scenarios and pull out a list of key nouns. These are candidate objects. Can these nouns be classified? Formalize the definitions of these classes. If you cannot define the class, then you can not call it a class. No cheating!
Go through the documented scenarios and pull out a list of key verbs. These should represent the associations between the nouns. Do these verbs describe is-a or has-a relationships between the defined classes? If so, we need to think about the multiplicity of these associations -- how many of one noun are related potentially to the other noun?
Some of the nouns will not classify in themselves but will represent attributes of some other class of objects. These attributes could as well take the form of adjectives. If the English is rather poor, other types may be attributes as well, or else they may represent associations or methods. In short, you are in trouble if you have not gotten a rudimentary grasp of basic English grammar somewhere in your primary education. Don't laugh, it's far more common than we care to admit!
Some verbs will not define is-a or has-a relationships, but will represent things that are done to a given class of objects. Although I say verbs, it may well be adverbs you will be finding. Typically, these will involve parameterization, and represent the behaviours, the methods or functions of a given class. Methods transform the state of a class of objects.
The state of the functionality can be represented by a state transition
diagram for the key entities or for that functional group. Note, state
must always be associated with some class, or group of classes.
It has no meaning apart from this.
How does object map to the RDBMS? Objects are either ephemeral, or persistant. All persistant objects need to have their state information preserved in the RDBMS. Classes of persistent objects will map into tables (or views) usually, and attributes of objects will map into fields (or columns). Objects will map into tuples (or rows). Methods and behaviours will need to be implemented in code.
Some terms that I will use:
The functionality of the system is determined by examining each actor to determine what the system must provide. Queries:
Activity: create a use-case diagram to illustrate system and all actors (i.e. diagram 0 DFD?); arrows represent flow of communication.
Where do we go to get the use-cases? Use-cases are discernable from the requirements documents, operations concepts, problem domain experts, users, and plain old common sense.
Validate the use-cases, using a prototype if necessary.
Use many scenarios to describe specific instances of use-cases. Scenarios are time-ordered expressions, expressed using natural language. Use specific instance of data.
OBJECTS An object is a thing, concept, or abstraction, something with well-defined boundaries, and has definition in terms of the application. Objects have state, behaviour and identity. Methods are used to transition from state to state.
State is one of the possible conditions in which an object may exist. State is represented by the properties of an object at a given time. State changes over time.
Behaviour determines how the object acts, reacts, changes state, and generally interacts with other objects. Another way to look at this is to think of it in terms of the set of operations that an object can perform.
CLASSES A class is a description of a group of objects with the same structure, behaviour, or relationship with some other object.
Objects are instantiations of a class. So a class is an abstraction of an object which emphasizes relevant common characteristics.
Classes are typically represented using a singular noun which characterizes the abstraction. Class names are verbatum from the problem domain name space. The description of the class should read as a glossary. Also, describe how you expect the class to be used. Never describe how the class is to be implemented.
If you are having trouble with any of the above, you probably have a poorly defined abstraction.
Scan the scenarios for nouns. Group nouns into classes. Beware, poor writing skills can result in the nounizing of verbs and vice versa.
Use a class diagram to represent the classes and inter-relationships. Class diagrams have the class name in the top compartment, the attributes in the middle compartment, and the methods in the bottom.
Relationships between classes can be association, or aggregation.
Association represents data flow. Direction may be in either direction. Multiple relations may exist between classes. Associations are named using verbs (verb phrase).
An associative relationship may define a role, instead. Role names are labelled at the end of the association line where it is closest to the class it modifies. A class "officer" associated with class "case" would be labelled "detective" near the officer end of the association line. Roles are nouns (noun phrases).
Associations will have an indication of multiplicity on each end. For example, it is possible for an officer (detective) to be working on more than one case (1:n). If it is possible for more than one officer to be assigned to each case, then multiplicity might be indicated as (n:n). Cases may be assigned to many officers, in which case a role is 1:n, and an association "assign" is n:1.
Multiplicity notation consists of a a number range attached to either end of the association line. Optionally, if no numbers are given, a large dot can represent zero or more. An empty dot, can represent zero or one. No dot means exactly one.
In the case of many to many relations, it may be desirable to express a link attribute. That is, given classes course & person, and a role association student, an attribute of grade would be stored in a class which is joined to the association via a semi-circle. This is the link attribute: it is only relevant in the context of a person, who is a student, who has a course, and it is per course instance. Some notations refer to link attribute as an associative relationship.
Aggregation is the "has-a" indicator. The diamond marks the end of the association which represents the whole. One whole contains potentially many elements of the class at the other end.
Associations may be reflexive. That is they might have an association with other objects of the same class. In this case the association indicator begins and ends at the same class.
Associations may have qualifiers. When one of the attributes in one of the classes reduces the multiplicity of the association, the attribute should be highlighted using a qualifier. The qualifier looks like a box on the association line, and the box contains the name of the attribute. The qualifiers appear at the end of the association line opposite of the class which defines the attribute. Attributes are taken from the problem domain name space. A class may be applicable to a number of different problem domains, in which case the view would supply different attributes. Attributes have clear, concise definitions.
Message trace diagram. Start time is at the top, end time is at the bottom. Dashed vertical lines represent objects. Horizontal arrows are messages passing through the objects. Arrows bare the message name. Message traces may be adorned with scripts. Scripts describe the object interactions in natural language, and are placed to the left of a message trace, aligned with the object interactions.
pp56onward todo
contact:
ejritz@home.com
Copyright (c) 2000 by E. J. Ritzmann.
$Date: 2000/11/07 03:38:20 $