ATM SYSTEM

FUNCTIONAL REQ.

Function Being Tested
Initial System State
Input
Expected Output
System Startup
System is started when the switch is turned "on"
System is off
Activate the "on" switch
System requests initial cash amount
System Startup
System accepts initial cash amount
System is requesting cash amount
Enter a legitimate amount
System is on
System Startup
Connection to the bank is established
System has just been turned on
Perform a legitimate inquiry transaction
System output should demonstrate that a connection has been established to the Bank
System Shutdown
System is shut down when the switch is turned "off"
System is on and not servicing a customer
Activate the "off" switch
System is off
System Shutdown
Connection to the Bank is terminated when the system is shut down
System has just been shut down

Verify from the bank side that a connection to the ATM no longer exists
Session
System reads a customer's ATM card
System is on and not servicing a customer
Insert a readable card
Card is accepted;System asks for entry of PIN
Session
System rejects an unreadable card
System is on and not servicing a customer
Insert an unreadable card
Card is ejected;System displays an error screen;System is ready to start a new session
Session
System accepts customer's PIN
System is asking for entry of PIN
Enter a PIN
System displays a menu of transaction types
Session
System allows customer to perform a transaction
System is displaying menu of transaction types
Perform a transaction
System asks whether customer wants another transaction
Session
System allows multiple transactions in one session
System is asking whether customer wants another transaction
Answer yes
System displays a menu of transaction types
Session
Session ends when customer chooses not to do another transaction
System is asking whether customer wants another transaction
Answer no
System ejects card and is ready to start a new session
Transaction
Individual types of transaction will be tested below



Transaction
System handles an invalid PIN properly
A readable card has been entered
Enter an incorrect PIN and then attempt a transaction
The Invalid PIN Extension is performed
Withdrawal
System asks customer to choose an account to withdraw from
Menu of transaction types is being displayed
Choose Withdrawal transaction
System displays a menu of account types
Withdrawal
System asks customer to choose a dollar amount to withdraw
Menu of account types is being displayed
Choose checking account
System displays a menu of possible withdrawal amounts
Withdrawal
System performs a legitimate withdrawal transaction properly
System is displaying the menu of withdrawal amounts
Choose an amount that the system currently has and which is not greater than the account balance
System dispenses this amount of cash;System prints a correct receipt showing amount and correct updated balance;System records transaction correctly in the log (showing both message to the bank and approval back)
Withdrawal
System verifies that it has sufficient cash on hand to fulfill the request
System has been started up with less than the maximum withdrawal amount in cash on hand;System is requesting a withdrawal amount
Choose an amount greater than what the system currently has
System displays an appropriate message and asks customer to choose a different amount
Withdrawal
System verifies that customer's balance is sufficient to fulfill the request
System is requesting a withdrawal ammount
Choose an amount that the system currently has but which is greater than the account balance
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Withdrawal
A withdrawal transaction can be cancelled by the customer any time prior to choosing the dollar amount
System is displaying menu of account types
Press "Cancel" key
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Withdrawal
A withdrawal transaction can be cancelled by the customer any time prior to choosing the dollar amount
System is displaying menu of dollar amounts
Press "Cancel" key
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Deposit
System asks customer to choose an account to deposit to
Menu of transaction types is being displayed
Choose Deposit transaction
System displays a menu of account types
Deposit
System asks customer to enter a dollar amount to deposit
Menu of account types is being displayed
Choose checking account
System displays a request for the customer to type a dollar amount
Deposit
System asks customer to insert an envelope
System is displaying a request for the customer to type a dollar amount
Enter a legitimate dollar amount
System requests that customer insert an envelope
Deposit
System performs a legitimate deposit transaction properly
System is requesting that customer insert an envelope
Insert an envelope
System accepts envelope;System prints a correct receipt showing amount and correct updated balance;System records transaction correctly in the log (showing message to the bank, approval back, and acceptance of the envelope)
Deposit
A deposit transaction can be cancelled by the customer any time prior to inserting an envelope
System is displaying menu of account types
Press "Cancel" key
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Deposit
A deposit transaction can be cancelled by the customer any time prior to inserting an envelope
System is requesting customer to enter a dollar amount
Press "Cancel" key
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Deposit
A deposit transaction can be cancelled by the customer any time prior to inserting an envelope
System is requesting customer to insert an envelope
Press "Cancel" key
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Deposit
A deposit transaction is cancelled automatically if an envelope is not inserted within a reasonable time
System is requesting customer to insert an envelope
Wait for the request to time out
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Transfer
System asks customer to choose an account to transfer from
Menu of transaction types is being displayed
Choose Transfer transaction
System displays a menu of account types specifying transfer from
Transfer
System asks customer to choose an account to transfer to
Menu of account types to transfer from is being displayed
Choose checking account
System displays a menu of account types specifying transfer to
Transfer
System asks customer to enter a dollar amount to transfer
Menu of account types to transfer to is being displayed
Choose savings account
System displays a request for the customer to type a dollar amount
Transfer
System performs a legitimate transfer transaction properly
System is displaying a request for the customer to type a dollar amount
Enter a legitimate dollar amount
System prints a correct receipt showing amount and correct updated balance;System records transaction correctly in the log (showing both message to the bank and approval back)
Transfer
A transfer transaction can be cancelled by the customer any time prior to entering dollar amount
System is displaying menu of account types specifying transfer from
Press "Cancel" key
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Transfer
A transfer transaction can be cancelled by the customer any time prior to entering dollar amount
System is displaying menu of account types specifying transfer to
Press "Cancel" key
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Transfer
A transfer transaction can be cancelled by the customer any time prior to entering dollar amount
System is requesting customer to enter a dollar amount
Press "Cancel" key
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Inquiry
System asks customer to choose an account to inquire about
Menu of transaction types is being displayed
Choose Inquiry transaction
System displays a menu of account types
Inquiry
System performs a legitimate inquiry transaction properly
System is displaying menu of account types
Choose checking account
System prints a correct receipt showing correct balance;System records transaction correctly in the log (showing both message to the bank and approval back)
Inquiry
An inquiry transaction can be cancelled by the customer any time prior to choosing an account
System is displaying menu of account types
Press "Cancel" key
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Invalid PIN Extension
Customer is asked to reenter PIN

Enter an incorrect PIN;Attempt an inquiry transaction on the customer's checking account
Customer is asked to re-enter PIN
Invalid PIN Extension
Correct re-entry of PIN is accepted
Request to re-enter PIN is being displayed
Enter correct PIN
Original transaction completes successfully
Invalid PIN Extension
A correctly re-entered PIN is used for subsequent transactions
An incorrect PIN has been re-entered and transaction completed normally
Perform another transaction
This transaction completes successfully as well
Invalid PIN Extension
Incorrect re-entry of PIN is not accepted
Request to re-enter PIN is being displayed
Enter incorrect PIN
An appropriate message is displayed and re-entry of the PIN is again requested
Invalid PIN Extension
Correct re-entry of PIN on the second try is accepted
Request to re-enter PIN is being displayed
Enter incorrect PIN the first time, then correct PIN the second time
Original transaction completes successfully
Invalid PIN Extension
Correct re-entry of PIN on the third try is accepted
Request to re-enter PIN is being displayed
Enter incorrect PIN the first time and second times, then correct PIN the third time
Original transaction completes successfully
Invalid PIN Extension
Three incorrect re-entries of PIN result in retaining card and aborting transaction
Request to re-enter PIN is being displayed
Enter incorrect PIN three times
An appropriate message is displayed;Card is retained by machine;Session is terminated
The software to be designed will control a simulated automated teller machine (ATM) having a magnetic stripe reader for reading an ATM card, a customer console (keyboard and display) for interaction with the customer, a slot for depositing envelopes, a dispenser for cash (in multiples of 100RUPEES), a printer for printing customer receipts, and a key-operated switch to allow an operator to start or stop the machine. The ATM will communicate with the bank's computer over an appropriate communication link. (The software on the latter is not part of the requirements for this problem.)
The ATM will service one customer at a time. A customer will be required to insert an ATM card and enter a personal identification number (PIN) - both of which will be sent to the bank for validation as part of each transaction. The customer will then be able to perform one or more transactions. The card will be retained in the machine until the customer indicates that he/she desires no further transactions, at which point it will be returned - except as noted below.
The ATM must be able to provide the following services to the customer:
A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of 100RUPEES. Approval must be obtained from the bank before cash is dispensed.
A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.
A customer must be able to make a transfer of money between any two accounts linked to the card.
A customer must be able to make a balance inquiry of any account linked to the card.
A customer must be able to abort a transaction in progress by pressing the Cancel key instead of responding to a request from the machine.
The ATM will communicate each transaction to the bank and obtain verification that it was allowed by the bank. Ordinarily, a transaction will be considered complete by the bank once it has been approved. In the case of a deposit, a second message will be sent to the bank indicating that the customer has deposited the envelope. (If the customer fails to deposit the envelope within the timeout period, or presses cancel instead, no second message will be sent to the bank and the deposit will not be credited to the customer.)
If the bank determines that the customer's PIN is invalid, the customer will be required to re-enter the PIN before a transaction can proceed. If the customer is unable to successfully enter the PIN after three tries, the card will be permanently retained by the machine, and the customer will have to contact the bank to get it back.
If a transaction fails for any reason other than an invalid PIN, the ATM will display an explanation of the problem, and will then ask the customer whether he/she wants to do another transaction.
The ATM will provide the customer with a printed receipt for each successful transaction, showing the date, time, machine location, type of transaction, account(s), amount, and ending and available balance(s) of the affected account ("to" account for transfers).
The ATM will have a key-operated switch that will allow an operator to start and stop the servicing of customers. After turning the switch to the "on" position, the operator will be required to verify and enter the total cash on hand. The machine can only be turned off when it is not servicing a customer. When the switch is moved to the "off" position, the machine will shut down, so that the operator may remove deposit envelopes and reload the machine with cash, blank receipts, etc.
The ATM will also maintain an internal log of transactions to facilitate resolving ambiguities arising from a hardware failure in the middle of a transaction. Entries will be made in the log when the ATM is started up and shut down, for each message sent to the Bank (along with the response back, if one is expected), for the dispensing of cash, and for the receiving of an envelope. Log entries may contain card numbers and dollar amounts, but for security will never contain a PIN.

Requirements example

User requirements are statements of user need, as expressed by the groups of stakeholders concerned with the system being developed. They address many aspects of the system, some behavioural and some not.
In general, behavioural user requirements are of one of two types: those that specify what is to be accomplished ( functional requirements), and those that specify how well the functions are to be accomplished ( performance requirements).
Non-functional requirements (NFRs), on the other hand, are often simply a catch-all term for all user requirements that are not explicitly functional. NFRs are sometimes referred to as non-behavioural rather than non-functional to more closely suit the process (e.g. OO-UML).
NFRs occur in many forms, including contractual or commercial statements, compliance with standards, environmental factors to be considered (such as temperature ranges, radiation levels or gradients to be climbed) and perhaps the most intangible (or difficult to address of all), the ilities. The ilities are typically expressions of the emergent properties of the system, the characteristics that its users desire that the system should exhibit once it is complete but which its component parts do not necessarily exhibit, or exhibit differently.

They include characteristics such as:

• Usability
• Reliability
• Maintainability
• Availability
• Survivability (for combat systems)
• Flexibility
• Adaptability

In the early design and development work, functional user requirements will normally get the most attention. There are modelling techniques (notations) such as the UML Use Case and Activity Diagrams, extended Function Flow Block Diagrams (eFFBD) or Behaviour Diagrams, which offer methods for depicting what operations are to be done in time sequence and the control logic that will control the flow of execution.
Treatment of the non-functional user requirements may not be so straightforward. We must first look at the basic types of NFRs:
Environment – requirements defining the physical environment (natural and induced) for system operation. In some cases, they may also address the political or economic setting in which the work is done or the system performs
Physical – requirements describing the form of the product or system. Examples include specifying the size, shape, paint finish, weight or other similar properties of products or systems.
Interface – requirements defining the data, structure and physical form of interfaces between components (hardware, software and people). There may also be a need to interface to existing systems or provide certain standard interfaces. Some requirements analysts classify interface requirements as a separate group, not as a type of NFR.
Constraints – requirements prescribing stipulations or limitations on how the system can be built, or how and in what context should other requirements apply. Non-technical aspects such as timeline and budget can also constrain development projects.
Quality Factors (Emergent Properties) – requirements that address other quality factors of the product or process, the ilities mentioned above.
A widely-used group of ilities is Reliability, Availability, and Maintainability (RAM) that arise in real-time defence, aerospace, process control, telecommunications and transport systems where the continual correct functioning of the product is important. RAM requirements are threatened by many kinds of risk or circumstance, such as design errors, operator overload or confusion, under-sized hardware and environmental factors (wind, rain, temperature variations, dust storms). These can cause hardware failures, software crashes, and human errors in judgement.
Other NFR ilities include testability, portability/mobility, usability, scalability, flexibility and supportability. Degradation in these or other quality factors incorporated as requirements will lead to system underperformance or failure. Usability can be compromised by an operator pushing the wrong button. Poor (or no) storability requirements lead to damage of delicate components; non-adherence to portability requirements may leave the system at the base and not in the field, and so on.
Not all quality factors are ilities in the strictest sense of the word. Requirements addressing security, system integrity and workmanship are important NFRs as well.
It is interesting to note that, whereas the behaviour diagrams and use cases describe the desired system operation and behaviour in functional terms (that is, to do this and then do that), the potential negative behaviour or misuses of the system lead to Non-Functional Requirements for protection and endurance.
Note also that NFRs at a high (entire system) level may lead to functions at the lower levels (subsystems or components). For example, a system-level safety requirement to suppress unwanted flames or burning material within a laboratory may lead to a sprinkler subsystem to protect the laboratory as a whole.
A key activity to address NFRs is the defining the physical architecture. One develops the system architecture by:
Defining the product structure (i.e. the component parts)
Allocating the required characteristics (e.g. colour, size, weight, MTBF, COTS equipment features) to the components
Specifying the interfaces between the component parts
This activity ensures that you address both functional and non-functional requirements during the system modelling and design process.
The aim for all analysis of user NFRs is to produce corresponding system NFRs that can be measured and tested and allocated into the system architecture. That is, the aim is to derive a collection of non-functional system requirements that:
Can be measured
Can be tested
Can be allocated to (that is, linked to) the system architecture

Non Functional Requirement Graphs
There are techniques and notations to address functional user requirements, both to produce functional system requirements and to develop architectural and behavioural models that support the system design. There are also graphical techniques to assist the development of non-functional system requirements from the non-functional user requirements.
One technique is the Non Functional Requirement Graph (NFRG), that have been discussed in the requirements literature for some years.
NFRGs start with non-functional user requirements and provide assistance to evolve these into corresponding non-functional system requirements that can be directly and meaningfully related to the system architecture:
NFRG Approach
In this approach, we start with the non-functional user requirements and express these as goals. That is, we start with the stakeholders’ statements in the original non-functional user requirements and create new derived requirements linked to these original statements that re-express the original statement as a goal, something that is to be achieved. An example is the classic (and possibly infamous!) goal “The system shall be easy to use”.
The aim of the NFRG is to help us to evolve these stakeholder goals into declarations held in the non-functional system requirements. These declarations are not detailed statements of what the system will be or what it will contain, but are expressions of the form of the solution to be described in the architecture. The declarations are consequently constraints on the form of the solution to the goal that will be built into the system.
The NFRG shows the transition between the goals and the solution constraints that satisfy them. This transition is shown as interlinking intermediate stages, which are initially sub-goals of the goals and become candidate solutions at we progress:
The intermediate goals and solutions are linked by lines that show the relationships between these intermediate NFRs.

NFRG Relationships
There are four types of relationship shown in a NFRG:
The meanings of these are:
Ensures. This relationship means that achieving B will, of itself, ensure that A is satisfied, irrespective of whether any other NFS linked to A is or is not achieved
Assists. This relationship means that achieving B will help to achieve A but achieving B does not, of itself, ensure that A is achieved
Impairs. This relationship means that achieving B will reduce the likelihood of achieving A but does not, of itself, mean that A cannot be achieved
Prevents. This relationship means that achieving B will, of itself, ensure that A cannot be achieved, irrespective of whether any other NFR linked to A is or is not achieved
The names of these relationships may change between different authors of NFRGs, but the concept of the relationships does not change. So, some authors may use a Guarantees relationship instead of Ensures, or Inhibits instead of Impairs.
The meanings of the relationships in the NFRG are deliberately imprecise. For example, there is nothing arithmetic about them, so that, for example:
It is not true to say that many Assists relationships are equal to an Ensures relationship. Neither is it true to say that if there are more Assists relationships than Impairs relationships then the net result is an Assists relationship. In this latter case, the NFRG is simply showing part of our decision making process, that some declarations assist achieving the goal and some impair it.
There are points of style here too. For example, having two sub-goals where one Ensures the goal and the other Prevents the goal may, or may not make sense. It may not make sense because if you achieve both sub-goals then achievement of the main goal is indeterminate. It may make sense if the aim of the NFRG is to document all aspects of the decision making process, and, in practice, both of the sub-goals cannot be achieved with the solution constraint that is ultimately shown in the NFRG.
The NFRG is a graph, not a hierarchy. Any sub-goal or candidate solution can be linked to more than one higher-level goal, sub-goal or candidate solution if that is what we want to show.

Benefits of Using NFRGs
Collectively the NFRG is a graphical justification for the assertion that the non functional system requirements do indeed satisfy and express the non functional user requirements.
Such justifications are always needed and always valuable. This justification is particularly valuable in connection with non-functional requirements since non-functional requirements are often inherently less precise and more subjective that the functional requirements. In turn, this means that the justification that a given set of non-functional system requirements is the best way to satisfy non-functional requirements (goals, desires and so on) from stakeholders is very much more difficult without NFRGs as an explanatory technique.
Finally, by being graphical, NFRGs are an ideal means to present the chains of decisions and reasoning that has produced the non-functional system requirements.
NFRG Example
For an example, we consider the goal “The system shall be easy to use” for a system that receives user inputs in response to questions and messages shown by the system, such as a car park ticket machine, or an airline ticket dispenser.
The non-functional user requirement, the goal, is shown at the top of the NFRG shaded in green, and the resulting solution constraints, the non-functional system requirements, are shown at the bottom of the NFRG shaded in blue.
The NFRG shows the justification that the non-functional system requirements “Use customkeypad” and “Use plasma display” satisfy the non-functional user requirement “Thesystem shall be easy to use”.

NFRGs in Cradle
Cradle fully supports NFRs and NFRGs. The manner in which the NFRs, goals, constraints and so on are actually represented in your project is your decision.
We can, however, offer some suggestions.
The non-functional requirements will usually be appropriately marked user requirements (URs) in the same way as the functional URs. The top-level goals can then either be user requirements (URs) as well, or they can be items of a new type, such as a new item type GOAL. The sub-goals would be implemented in the same way as the goals. The candidate solutions and solution constraints could also be items of a new type, such as CONSTRAINT, or they could be system requirements (SRs) in the same manner as functional (behavioural) SRs. As a final choice, you could choose to have a single new item type, such as NFR, for all of the goals, sub-goals, candidate solutions and solution constraints that you would represent in your NFRGs.
The relationships shown in the NFRG are cross references in the Cradle database with link types ENSURES, ASSISTS, IMPAIRS and PREVENTS.
The NFRG itself is a Hierarchy Diagram (HID). These diagrams are generated dynamically on demand by Cradle, both within the UIs of the Cradle tools and also when included in a document generated from the Cradle database by the Document Publisher tool.
To use NFRs in Cradle you will:
Create appropriate item types in your schema, based on the suggestions above
Create appropriate link types in your schema, based on the suggestions above
Create the URs from your stakeholders, as you would do normally
Create the goals from these URs
Create the sub-goals and link them to the goals using the appropriate link type from those that you have just created, normally by drag-and-drop in WorkBench between trees showing the URs, the goals, the sub-goals and their evolution so far
Proceed in the same way to evolve the sub-goals through as many levels as you need
Proceed in the same way to create potential candidate solutions and evolve them
Proceed in the same way to create solution constraints
Link the solution constraints to non-functional SRs, unless you have decided that the solution constraints are the non-functional SRs themselves (which they certainly could be)
At any time, you produce a NFRG by simply displaying a Hierarchy Diagram starting at any of the URs, the goals or sub-goals.

System Modelling

1. Overview
System modelling is a technique to express, visualise, analyse and transform the architecture of a system. Here,
a system may consist of software components, hardware components, or both and the connections between these
components. A system model is then a skeletal model of the system.
System modelling is intended to assist in developing and maintaining large systems with emphasis on the
construction phase. The idea is to encapsulate complex or changeable aspects of a design inside separate
components with well-defined interfaces indicating how each component interacts with its environment.
Complete systems are then developed by composing these components. System modelling can increase
reliability and reduce development cost by making it easier to build systems, to reuse previous built components
within new systems, to change systems to suit changing requirements such as functional enhancement and
platform changes, and to understand systems. In this way, a system model can satisfy different requirements
such as documenting the system, providing a notation for tools such as consistency checkers and can also be
used in the design stage of system development.
Thus, system modelling is used to ensure that a developing piece of software evolves in a consistent manner
and that the task of integrating software components is simplified.
1.1 Modelling framework and language
For system modelling, we need a conceptual framework and a system modelling language, textual and/or
diagrammatic. Besides textual notations like tables or prose, diagrammatic notations like graphs are common
today. Within these diagrams, there are symbols representing the parts of the system, e.g. objects and groups of
objects, and other symbols visualising the connections between these parts. The number of symbols for each
purpose differs noticeably between notations.
During the past decades four main conceptual frameworks have evolved:
· Design Methods
· Module Interconnection Languages (MILs)
· Software Architectures
· Design Patterns
Design methods focusing on program language modules date back to the early seventies; modelling systems
with objects is a technique of the late eighties. The first MIL was presented 1975, and in the following years a
lot of different MILs have been developed. In contrast, software architectures and design patterns are more
recent techniques and are each only about five years old.
1.2 Design methods
Design methods consist of a concept, a language, and a design process. The concept defines which parts of the
program are to be represented by the components of the system model. The language is used to describe the
system model. To carry out the design of the system according to the software lifecycle or a part of it, a step-bystep
process is given to be followed by the designer.
When modelling a system with a modular design method, program modules are used as the components of
which the system is composed. Modules include related functions of a specific program language and may keep
the data used by these functions. Further, a module offers an interface with the functions that may be used from
this module.
An interrelationship between two modules is established by a function contained in one module calling a
function contained in an other. Thus, this modelling method describes systems in terms of function calls and
composition of modules containing functions.
A commonly used example is Structured Design (SD) introduced by Constantine and Yourdon at the end of the
Seventies; Modular Design (MD) is an extension of SD, subdividing the system to be designed into modules
which can be developed independently of each other.
Object-oriented design methods, on the other hand, do not focus on the functional aspect. An object component
includes data and functions. These functions constitute an external interface, and represent the only possibility
2
to manipulate and/or access the data within an object. Another type of components are classes, which serve as
templates from which objects can be instantiated, i.e. derived.
The connections between the objects of a system model are manifold, e.g. instantiation of an object from a class,
composition, and use. Interacting objects often are not viewed as calling each other’s functions, but requesting
each other via messages to perform a desired action on their data. An object is responsible that its
representation is hidden from other objects. Thus, the object-oriented modelling method adds behaviour over a
mere structural solution.
A design method on the verge to object-oriented design is MD++, mainly MD with an object-oriented
extension. Other methods focus on a particular implementation language, e.g. HOOD (Hierarchical Object-
Oriented Design) is used to develop systems with the ADA implementation language. Today’s widely used
object-oriented methods include the Object Modelling Technique (OMT) by Rumbaugh, the Object-Oriented
Design and Analysis (OODA) by Booch, the Object-Oriented Design LanguagE (OODLE) by Shlaer, and
Ooram (Object-Oriented role modelling) by Reenskaug.
For both modular and object-oriented design methods there exist textual and diagrammatic notations coming
with the specific design methods, with diagrammatic notations becoming common during the last years.
Besides these two main design methods there exist design methods for special purposes like task design, which
is focusing on processes and their communications, and real-time systems design.