[RFC] SRS Section 3

Jeremy Huntwork jhuntwork at linuxfromscratch.org
Fri Feb 4 07:45:48 PST 2005


Ok Everyone. this is the big one. I think just from our discussions over 
the past few days we all likely have a clearer picture of what exactly 
it is that we're after with the new tool.

Besides commenting on the text that is currently here, please put 
forward anything you think is missing.

--
Jeremy H.

========================================================================

3. Specific Functional Requirements
3.1 Functionality

{This section describes the functional requirements of the system for 
those requirements that are expressed in the natural language style. For 
many applications, this may constitute the bulk of the SRS package and 
thought should be given to the organization of this section. This 
section is typically organized by feature, but alternative organization 
methods may also be appropriate; for example, organization by user or 
organization by subsystem. Functional requirements may include feature 
sets, capabilities, and security. Where application development tools, 
such as requirements tools, modeling tools, and the like, are employed 
to capture the functionality, this section of the document would refer 
to the availability of that data, indicating the location and name of 
the tool used to capture the data.}

3.1.1 Profile Validation & Parsing

alfs will fully support both XML profile validation and parsing. 
Validation and parsing are two seperate things. Validation is the 
process with which an XML document (in our case a profile) conforms to 
the DTD properly and is fully valid XML. Parsing is the process with 
which a system takes a valid XML document and rips it apart into useful 
pieces. alfs needs both fully valid XML profiles and excelleent parsing 
capabilities to function correctly. alfs will support both GUI and 
command line support for validating a profile.

As part of the validation process, alfs will also support the capability 
to check all packages referenced in a profile against their md5sums 
before build time.

See Parsing, Relax-NG and md5sums for more details.

3.1.2 Conditional Execution

One of the major problems with the current nALFS is that there is no way 
to handle conditional execution (if, then, else). To really make alfs 
the premier LFS build tool, there has to be a way to handle conditions. 
Not every system is static and if the tool is going to be able to handle 
cross-building and other advanced features, then conditional execution 
is definitely needed. There is no detail page for this, just a few bugs. 
The new ALFS DTD v3.2 that will be used for alfs will contain the 
required elements for conditional execution and the handlers will need 
to be built to do the work.

3.1.3 Package Manager Functions

alfs will support basic package manager type functions. This will come 
mostly with the new logging facility. As such the new tool will support 
full dependancy resolution, uninstallation, reinstallation, proper umask 
support, etc. The GUI will also support a feature to allow a person to 
query on what is installed on a system, look at dependancy trees for a 
certain package (like what has been installed and what needs to be 
installed), and provide gory details on a package's installation.

See Dependencies for details on the dependancy feature.

3.1.4 Logging DTD

As mentioned above, alfs will support a new logging DTD. The logging 
facility is geared towards the package manager type functions, but also 
is an excellent way to gather details on SBU data, iterative comparison 
of builds and other such things that LFSers are interested in. The idea 
of the logging DTD is to provide a single source of log type data from 
an entire build process. The log files will support apending data to the 
end, so that if you build a package more than once, you can see the 
difference.

See 
http://linuxfromscratch.org/pipermail/alfs-discuss/2004-February/004585.html 
for a good start of a conversation on this topic. You can also refer to 
Logging.

3.1.5 Split of Front End and Back End

alfs will support a seperation of front and back end to complete a 
client/server architecture. In a client/server architecture the daemon 
is the process that does all the hard grunt work and the client is just 
a smaller application that connects to and manipulates a running 
process. The alfs implementation of the client/server model will be the 
same, but instead of the daemon running on a remote server, it will run 
on the target box (e.g. the one that you want a new shiny LFS on). The 
daemon will run as a service on a box and will have access to statefull 
information like profile logs, shared object handlers, xml validation 
and parsing code, etc. It will not provide a gui.

The client will be the gui. It will connect to the daemon (on the same 
box or from a remote one). It will be responsible for telling the daemon 
what profile to load and what to do with it (e.g. validate it, run it, 
select only a section to run, look at and analyze a log, etc.)

See SplitnALFS for all details on this functional requirement.

For the implementation of a client/server architecture, we need a 
clearly defined and supportable communication protocol between both 
sides. The only requirement is that it needs to be one in use today in 
the rest of the world. We do not want to create our own when so many 
already exist to choose from.

See Protocol for all details on this functional requirement.

3.1.6 General GUI Featured Updates

There are a number of features that the current GUI lacks. See the main 
BZ list on nALFS2Develpment for a good list of what we are looking at 
implementing. Ideas include

     * Marking (highlighting) different interesting elements
     * Support for interactive commands in <execute>
     * Enumerate all screen parts for coloring
     * Support for configuring colors
     * Progress indicator when downloading files
     * Command for checking archives and <unpack>'s URLs
     * Remove handler-specific things from the main code
     * Performing an action on all marked elements
     * Editing and reloading .nALFSrc from the program
     * Flag to silently ignore failure

3.2 Usability

{This section includes all those requirements that affect usability. For 
example, specify the required training time for a normal user and a 
power user to become productive at particular operations; specify 
measurable task times for typical tasks or base the new system’s 
usability requirements on other systems that the users know and like 
specify requirement to conform to common usability standards, such as 
IBM’s CUA standards Microsoft’s GUI standards}

3.2.1 Internationalization

The LFS community is made up of many people from many nationalalities 
and native languages. nALFS should support a facility of i18n plugins. 
The native language of the tool will be English, but should support the 
ability of any native language given a person to write a translation.
3.3 Reliability

{Requirements for reliability of the system should be specified here. 
Some suggestions follow: Availability—specify the percentage of time 
available ( xx.xx%), hours of use, maintenance access, degraded mode 
operations, and so on; Mean Time Between Failures (MTBF) — this is 
usually specified in hours, but it could also be specified in terms of 
days, months or years; Mean Time To Repair (MTTR)—how long is the system 
allowed to be out of operation after it has failed?; Accuracy—specifies 
precision (resolution) and accuracy (by some known standard) that is 
required in the system’s output; Maximum Bugs or Defect Rate—usually 
expressed in terms of bugs per thousand lines of code (bugs/KLOC) or 
bugs per function-point( bugs/function-point); Bugs or Defect 
Rate—categorized in terms of minor, significant, and critical bugs: the 
requirement(s) must define what is meant by a "critical" bug; for 
example, complete loss of data or a complete inability to use certain 
parts of the system’s functionality.}

3.3.1 {reliability requirement one}

     {The requirement description}

3.4 Performance

{The system’s performance characteristics are outlined in this section. 
Include specific response times. Where applicable, reference related Use 
Cases by name. Response time for a transaction (average, maximum); 
Throughput, for example, transactions per second; Capacity, for example, 
the number of customers or transactions the system can accommodate; 
Degradation modes (what is the acceptable mode of operation when the 
system has been degraded in some manner); Resource utilization, such as 
memory, disk, communications, and so forth.}

3.4.1 {performance requirement one}

     {The requirement description}

3.5 Supportability

{This section indicates any requirements that will enhance the 
supportability or maintainability of the system being built, including 
coding standards, naming conventions, class libraries, maintenance 
access, and maintenance utilities}

3.5.1 {supportability requirement one}

     {The requirement description}

3.6 Design Constraints

{This section indicates any design constraints on the system being 
built. Design constraints represent design decisions that have been 
mandated and must be adhered to. Examples include software languages, 
software process requirements, prescribed use of developmental tools, 
architectural and design constraints, purchased components, class 
libraries, and so on.}

3.6.1 {design constraints requirement one}

     {The requirement description}

3.7 On-line User Documentation and Help System Requirements

As with any good application, documentation and help facilities will 
exist for alfs. Current documents are the ALFS DTD Syntax Document, 
nALFS Users Guide and nALFS Hackers Guide. These will migrate to the new 
application as will a new ALFS Logging DTD Syntax Document. These four 
books/guides should suffice for any help a user may need.
3.8 Purchased Components

alfs is an open-source tool and as such will use absolutely no purchased 
components. Everything that alfs will need is already available in an 
OSS format.
3.9 Interfaces

{This section defines the interfaces that must be supported by the 
application. It should contain adequate specificity, protocols, ports 
and logical addresses, and the like, so that the software can be 
developed and verified against the interface requirements.}

3.9.1 User Interfaces

     {Describe the user interfaces that are to be implemented by the 
software.}

3.9.2 Hardware Interfaces

     {This section defines any hardware interfaces that are to be 
supported by the software, including logical structure, physical 
addresses, expected behavior, and so on.}

3.9.3 Software Interfaces

     {This section describes software interfaces to other components of 
the software system. These may be purchased components, components 
reused from another application or components being developed for 
subsystems outside of the scope of this SRS but with which this software 
application must interact.}

3.9.4 Communications Interfaces

     {Describe any communications interfaces to other systems or devices 
such as local area networks, remote serial devices, and so fo rth.}

3.10 Licensing Requirements

nALFS will be licensed under the GPL.
3.11 Legal, Copyright and Other Notices

Since alfs will be licensed under the GPL, there are no notices. All are 
handled by the GPL.
3.12 Applicable Standards

{This section describes by reference any applicable standard and the 
specific sections of any such standards which apply to the system being 
described. For example, this could include legal, quality and regulatory 
standards, industry standards for usability, interoperability, 
internationalization, operating system compliance, and so forth.}



More information about the alfs-discuss mailing list