Session 6b: Specifying constraints

Size: px

Start display at page:

Download "Session 6b: Specifying constraints"

Samson Russell
5 years ago
Views:

1 Session 6b: Specifying constraints Analysis vs. Design Constraints on the end product Constraints on the development COMP 320 / 420 Spring, 2018 Mr. Weisert "Analysis & Design" (review from session 1) There is no such single discipline or activity, despite many book titles, etc. They are two separate activities: done at different times during a project done (usually) by different people requiring different skills The analyst specifies WHAT the proposed new application will do. The designer determines HOW the proposed application will do it. This course is about systems analysis. "Non-functional requirements" Some authors, especially those who advocate a discrete requirements list methodology like that term: What they call "functional requirements" are bona fide specifications for the proposed new application system. Those requirements specify what the system is to do. What they call "non-functional requirements" are actually restrictions upon the project. Many (not all) of them are unnecessary or premature in this phase of a project. We prefer the more accurate term "constraint". Part 1: overview summary of the kinds of constraint A. Constraints on the end product (What we build) B. Constraints on the development project (How we build it) COMP 320, spring copyright 2010 Conrad Weisert

2 A: Constraints on the end product Performance constraints Availability Reliability Transaction response time Batch run time Interfaces with other application systems Environment Hardware Operating system Network deployment DBMS Analyst should usually specify these Analyst should try to avoid specifying these B: Constraints on the project Development tools Programming language Editor, source library control, etc. Use of software libraries or application products Methodology Programming paradigm Analyst should try to avoid specifying these Activity sequence, etc. Organization Use of contract development firm Choice or qualifications of personnel Why would a systems analyst want to specify any of those? Implicit constraints Most large organizations have a body of I.T. standards that specify many of the choices we've just discussed. Those standards and conventions apply to every project in the organization, whether done by in-house staff or by a contractor. The analyst needs to specify a constraint only when it has to deviate from or augment those organization-wide standards. Who approves the deviation? Part 2: Some important constraints a. Constraints that the systems analyst should always (usually) specify as part of the ESD. b. Constraints that the systems analyst may specify in unusual situations. c. Constraints that the systems analyst should try to avoid specifying. s? COMP 320, spring copyright 2010 Conrad Weisert

3 Situation We've installed a new application system for a demanding user organization. During the first six months of operation The system goes down ("crashes") 5 times with outages lasting between five minutes and 50 minutes. One of those crashes resulted in lost transactions requiring re-entry of two hours worth of high-volume input data. Data entry clerks complain the response time is often sluggish in the late afternoon. User management is irate, proclaiming the system a failure. Whose fault is this? Managing expectations Many users are naive about operational performance: They expect perfection! Why? Every failure or complaint is a "black mark" against the system (and its developers) When a certain number of black marks are accumulated, users rebel. The analyst must prepare the sponsoring users for reality: Perfection is unattainable We can usually get closer to it if we spend more money and take more time. How? Specifying on-line availability System Q will be available to on-line users between 07:30 and 18:00 (EST) Monday through Saturday. Incidents of unplanned unavailability (outages) will occur no more than: up to 5 minutes once a month 5 to 20 minutes twice a year up to 4 hours once in 2 years How can the analyst know that's possible? What if the user says it's unacceptable? Specifying reliability File maintenance transactions may be lost and require re-entry no more than: 15 minutes worth twice in 6 months 60 minutes worth once in 2 years Undetected system errors resulting in erroneous account information will never occur. How can the analyst know that's possible? What if the user says it's unacceptable? COMP 320, spring copyright 2010 Conrad Weisert

4 Specifying response time Order status inquiry transactions will display results in 0.5 seconds (avg.) 4.0 seconds (max.) Keystrokes on all on-line data entry (forms or dialogs) will be displayed instantly (0.1 sec.) How can the analyst know that's possible? What about Internet deployment? What if the user says it's unacceptable? Specifying batch turn-around Month-end accounts reconciliation run will take no longer than 2 hours elapsed time, starting after on-line shut-down the last working day of the month. Negotiating reliability and performance Sponsoring users may be alarmed when they first hear mention of failures or sluggish response, however infrequent. We can give them choices: Everything has a price. You can spend more (and wait longer) to get faster, more reliable operation. The choice depends upon the nature of the application. How do we involve the prospective developers? The other side of negotiation We expect the user community to press for higher reliability and faster response time. But the prospective developers may take the opposite view! Remember that the developers (or vendors) are the second audience for the ESD. They get a chance to approve or reject performance constraints based on their expertise. Outside contractors (developers or software product vendors) should be required to include the performance constraints in the formal contract. COMP 320, spring copyright 2010 Conrad Weisert

5 Levels of reliability and performance for different kinds of application 1. Application used by internal staff. They will be inconvenienced by failures. 2. Applications that affect outside people. Our company will be embarrassed. 3. Applications that can cause hardship (such as?) to outside people We may get sued. 4. Super-critical applications People may die Prolonged negotiations We may not know enough about the feasibility and cost of a committed level of performance and reliability until some internal design work is done. What can we do about that? Platform constraints In the mainframe era this was easy: If the organization had million-dollar machines with plenty of capacity, you needed overwhelming justification to deploy an application on anything else. Today we may have options: Server Shared Dedicated Internet ("cloud") Operating system UNIX Windows etc. Work stations Desktop Dumb terminals Portables DBMS Oracle SQL Server etc. Does the analyst have to worry about the platform? Often not The organization may have established a standard operating environment machines system software support staff If that's an acceptable platform for the new application, just accept it. Otherwise, trust the devlopers to use their judgment COMP 320, spring copyright 2010 Conrad Weisert

6 Avoiding unnecessary platform constraints Avoid using physical or implementationspecific terms to label DFD elements Windows PC Server Oracle database Those can be specified later during the design phase. Specifying the configuration The analyst may and often should state: The minimum logical configurations required (needn't work on anything smaller) The impact on capacity of shared resources (must we upgrade the configuration?) Who needs that information, and what will they do with it? Those are just estimates. Later system design will make them firm. Minimum logical configuration Today's distributed platforms make this harder to specify than it used to be. But we still have to try: to help estimate operating cost. to avoid surprising the central I.T. facility to provide lead time for ordering equipment. Some components (clients, servers, network): Permanent ("persistent") storage Transient memory (real / virtual) Processor speed Network capacity etc. etc, etc. Does a systems analyst know how to estimate these? If not, what do we do? Specifying interfaces to other application systems Three possibilities: 1. The proposed new system will send output (by communication link or file) to another system. 2. The proposed new system will receive input from another system. 3. The proposed new system will share a database with another system a. The database must be used without change, or b. The project can specify additions and changes. Are these really constraints, or just output / input specifications? COMP 320, spring copyright 2010 Conrad Weisert

7 Development constraints Programming languages and other tools Documentation standards Use of contractors etc. Why would we care about that at this phase of the project? Is that any of the users' or the analyst's business? Specifying project constraints: Why would an analyst want to? a. The systems analyst may also be the project manager, who will be responsible for building and installing the proposed new application. b. The systems analyst may be a former senior programmer, who has strong opinions (or biases) about development methodology. c. The systems analyst may currently also be a senior programmer, who will actually participate in building the new application. Which of those is a valid reason? Making suggestions The analyst is always free to suggest a technique or approach, based on special knowledge of the application system preferences expressed by the sponsoring users. Unless such a suggestion is specifically flagged as a constraint the developers are free to use their judgment whether to comply. How do we flag it? COMP 320, spring copyright 2010 Conrad Weisert

Session 2. Getting started with a well-structured system specification

Session 2. Getting started with a well-structured system specification Session 2 Getting started with a well-structured system specification COMP 320/420 Spring, 2018 Conrad Weisert The situation A representative approaches us. (or vice versa) He or she may be a. an executive